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© A file editing system for realizing a high file 
content secrecy, a file version management, and an 
asynchronous editing. For a high file content se- 
crecy, the block data of files managed by the file 
management server device are enciphered in units 
of blocks, and the client device obtains the block 
data of the desired file in enciphered state, de- 
ciphers the obtained block data in units of blocks, 
carries out an editing of the desired file to obtain 
editing data, enciphers the editing data in units of 
blocks, and transmits the enciphered editing data to 
the file management server device. For asynchro- 
nous editing, the system includes a unit for generat- 
ing editing procedure data indicating a procedure to 
obtain the editing made in the desired version of the 
desired file by each client device, a unit for convert- 
ing the editing procedure data for the desired ver- 
sion of the desired file into the editing procedure 
data for the latest version of the desired file, a unit 



for generating record management information in- 
dicating a result of the editing made by each client 
device according to the editing procedure data for 
the latest version of the desired file. 
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BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates to a file editing 
system for realizing asynchronous editing of a 
shared file by a plurality of users and a file content 
reading protection in a computer based shared file 
system or database system. 

Description of the Background Art 

In a computer system, in order to manage the 
accesses from a plurality of users with respect to a 
resource within the system, it has been pointed out 
that it is necessary to provide an authentication 
mechanism for confirming whether a user issuing 
an access request is a proper user who has an 
access right with respect to that resource or not. In 
particular, under an environment of a large scale 
system in which an access from a remote user is 
permitted, such an authentication mechanism be- 
comes very important. A representative conven- 
tional system for realizing such an authentication 
mechanism is the Kerberos. 

A typical conventional system which requires 
such an authentication mechanism is the CSCW 
(Computer Supported Cooperative Work). The 
CSCW is a generic name for computer systems 
which assist the cooperative work of a plurality of 
users, and the shared file system is its most basic 
and typical example. In the shared file system, a 
plurality of users have access rights such as 
"read" and "write" with respect to the identical file, 
and the system can realize the editing work without 
causing any contradiction while allowing the ac- 
cesses by these users with respect to the identical 
file simultaneously. 

Conventionally, a general format for realizing 
such a shared file system has been the client 
server type in which the client as a subject which 
makes accesses to the files and the server which 
manages the files are separated, and the authen- 
tication system for carrying out the authentication 
of the accesses from the client is implemented 
therein. That is, the server authenticates the proper 
access right of the client, and if necessary, the 
server also carries out the enciphering of the data 
to be transmitted between the client, while the 
client authenticates the properness of the connect- 
ed server. Conventionally known examples of such 
a shared file system include the Lotus Notes. 
There is also a system called CFS (Cryptographic 
File System) which is known as an example of a 
file system in which the enciphering of the file 
contents can be carried out by the diet. 

As this type of a shared file system becomes 
more wide ranging in its service, it can be ex- 
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pected that there arises a need for a service format 
in which only a file server is required at a certain 
site. Namely, it is a format in which the file man- 
agement and the access management are pro- 

5 vided, but the file contents cannot be read out at 
the server itself. However, this type of service 
cannot be realized by using the conventional secu- 
rity system because the conventional security sys- 
tem only protects the communication data and the 

10 file contents at the server are managed in forms of 
plain texts. 

Also, in the conventional mechanism for realiz- 
ing the simultaneous editing on the shared file, 
while one user is carrying out the editing which 

75 uses the writing with respect to a certain file, what 
the other users can do with respect to the same file 
is restricted to the reading at best. Thus, this is not 
a real simultaneous editing strictly speaking, and it 
is merely realizing a synchronous editing in which 

20 the synchronization is made by utilizing the locking 
mechanism so as to avoid the contradiction among 
the accesses from a plurality of users. Namely, 
while the first access requesting user makes an 
access, the locking mechanism is activated such 

25 that the file access request for writing from the 
other user is not permitted, and the other user is 
forced to suspend the file access temporarily, await 
for the release of the lock, and try the file access 
again after the lock is released. 

30 In this regard, a more flexible system can be 

realized if it is possible to allow one user to carry 
out the editing which uses the writing with respect 
to a certain file even when the other user is carry- 
ing out the editing which uses the writing with 

35 respect to the same file. In the following, this type 
of operation will be referred as asynchronous ed- 
iting in a sense that there is no need to make the 
synchronization among the accesses which are 
randomly generated by a plurality of users. 

40 On the other hand, another technique related to 

the shared file system is the version management 
technique. The conventionally known version man- 
agement schemes include the SCCS (Source Code 
Control System) and the RCS (Revision Control 

45 System). Such a version management scheme 
achieves the compression of the file size by main- 
taining only a difference between different versions 
instead of maintaining the files at a given moment 
entirely, in a circumstance such as that of a pro- 

50 gram development by a plurality of programmers. 
However, despite of its advantage regarding the 
reduced file size, its incorporation into the shared 
file system has been limited so far to a case of the 
synchronous editing using the locking mechanism. 

55 
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SUMMARY OF THE INVENTION 

It is therefore an object of the present invention 
to provide a file editing system capable of realizing 
a higher level of secrecy such that the file contents 
cannot be read from the file server. 

It is another object of the present invention to 
provide a shared file editing system which supports 
the file version management, which is capable of 
realizing the asynchronous editing. 

It is another object of the present invention to 
provide a shared file editing system which supports 
the file version management, which is capable of 
realizing the asynchronous editing while keeping 
the file contents secret from the file server. 

According to one aspect of the present inven- 
tion there is provided a file editing system, com- 
prising: a file management server device for man- 
aging files, each file containing a plurality of block 
data and block identification information for each 
block data, the block data being enciphered in 
units of blocks, and the file management server 
device managing the files according to the block 
identification information for each block data; and at 
least one client device, which makes an access to 
the file management server device to obtain the 
block data belonging to a desired file managed by 
the file management server device, the client de- 
vice including: deciphering means for deciphering 
the block data obtained from the file management 
server device, in units of blocks by using a pre- 
scribed decipher key; editing means for editing the 
desired file formed by the block data deciphered 
by the deciphering means to obtain editing data 
indicating an editing made in the desired file; enci- 
phering means for enciphering the editing data 
obtained by the editing means, in units of blocks 
by using a prescribed cipher key, to obtain enci- 
phered editing data; and communication means for 
transmitting the enciphered editing data obtained 
by the enciphering means to the file management 
server device, such that the file management serv- 
er device manages the desired file according to the 
enciphered editing data received from the client 
device. 

According to another aspect of the present 
invention there is provided a file editing system, 
comprising: a file management server device for 
managing files, each file containing a plurality of 
block data and block identification information for 
each block data, and the block data being enci- 
phered in units of blocks; and at least one client 
device, which makes an access to the file manage- 
ment server device to obtain the block data cor- 
responding to a desired version of a desired file 
managed by the file management server device, 
the client device including: deciphering means for 
deciphering the block data obtained from the file 
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management server device, in units of blocks by 
using a prescribed decipher key; editing means for 
editing the desired version of the desired file 
formed by the block data deciphered by the de- 

5 ciphering means; editing procedure generation 
means for generating editing procedure data in- 
dicating a procedure to obtain an editing made in 
the desired version of the desired file by the ed- 
iting means; editing procedure conversion means 

w for converting the editing procedure data for the 
desired version of the desired file generated by the 
editing procedure generation means into editing 
procedure data for a latest version of the desired 
file; record management information generation 

75 means for generating record management informa- 
tion indicating a result of the editing made by the 
editing means, according to the editing procedure 
data for the latest version of the desired file ob- 
tained by the editing procedure conversion means; 

20 enciphering means for enciphering the record man- 
agement information generated by the record man- 
agement information generation means, in units of 
blocks by using a prescribed cipher key, to obtain 
enciphered record management information; and 

25 communication means for transmitting the enci- 
phered record management information obtained 
by the enciphering means to the file management 
server device; wherein the file management server 
device includes: record management means for 

30 carrying out a record management of the desired 
file according to the enciphered record manage- 
ment information received from the client device 
and the block identification information for each 
block data. 

35 According to another aspect of the present 

invention there is provided a file editing system, 
comprising: a file management server device for 
managing files, each file containing a plurality of 
block data and block identification information for 

40 each block data; and at least one client device, 
which makes an access to the file management 
server device to obtain the block data correspond- 
ing to a desired version of a desired file managed 
by the file management server device, the client 

45 device including: deciphering means for decipher- 
ing the block data obtained from the file manage- 
ment server device, by using a prescribed decipher 
key; editing means for editing the desired version 
of the desired file formed by the block data de- 

50 ciphered by the deciphering means; editing proce- 
dure generation means for generating editing pro- 
cedure data indicating a procedure to obtain an 
editing made in the desired version of the desired 
file by the editing means and including insertion 

55 data to be inserted into the desired file; enciphering 
means for enciphering the insertion data included 
in the editing procedure data generated by the 
editing procedure generation means, by using a 

3 
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prescribed cipher key, to obtain enciphered editing 
procedure data; and communication means for 
transmitting the enciphered editing procedure data 
obtained by the enciphering means to the file man- 
agement server device; wherein the file manage- 
ment server device includes: editing procedure 
conversion means for converting the enciphered 
editing procedure data for the desired version of 
the desired file received from the client device into 
enciphered editing procedure data for a latest ver- 
sion of the desired file; record management in- 
formation generation means for generating record 
management information indicating a result of the 
editing made by the editing means, according to 
the enciphered editing procedure data for the latest 
version of the desired file obtained by the editing 
procedure conversion means; and record manage- 
ment means for carrying out a record management 
of the desired file according to the record manage- 
ment information obtained by the record manage- 
ment information generation means and the block 
identification information for each block data. 

According to another aspect of the present 
invention there is provided a shared file editing 
system, comprising: a file management server de- 
vice for managing files, each file containing a plu- 
rality of block data and block identification informa- 
tion for each block data; a plurality of client de- 
vices, each client device making an access to the 
file management server device to obtain the block 
data corresponding to a desired version of a de- 
sired file managed by the file management server 
device, and editing the desired file formed by the 
block data obtained from the file management serv- 
er device; and asynchronous editing support 
means for supporting asynchronous editing by said 
plurality of client devices, including: editing proce- 
dure generation means for generating editing pro- 
cedure data indicating a procedure to obtain each 
editing made in the desired file by each client 
device; editing procedure conversion means for 
converting the editing procedure data for the de- 
sired version of the desired file generated by the 
editing procedure generation means into editing 
procedure data for a latest version of the desired 
file; and record management information generation 
means for generating record management informa- 
tion indicating a result of the editing made in the 
desired file by each client device, according to the 
editing procedure data for the latest version of the 
desired file obtained by the editing procedure con- 
version means, such that the file management 
server device manages the desired file according 
to the record management information and the 
block identification information for each block data. 

According to another aspect of the present 
invention there is provided a method of file editing 
in a file editing system formed by a file manage- 
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ment server device and at least one client device, 
comprising the steps of: managing files at the file 
management server device, each file containing a 
plurality of block data and block identification in- 

5 formation for each block data, the block data being 
enciphered in units of blocks, and the file manage- 
ment server device managing the files according to 
the block identification information for each block 
data; making an access to the file management 

10 server device to obtain the block data belonging to 
a desired file managed by the file management 
server device, at the client device; deciphering the 
block data obtained from the file management serv- 
er device, in units of blocks by using a prescribed 

75 decipher key, at the client device; editing the de- 
sired file formed by the block data deciphered by 
the deciphering step to obtain editing data indicat- 
ing an editing made in the desired file, at the client 
device; enciphering the editing data obtained by 

20 the editing step, in units of blocks by using a 
prescribed cipher key, to obtain enciphered editing 
data at the client device; and transmitting the enci- 
phered editing data obtained by the enciphering 
step from the client device to the file management 

25 server device, such that the file management serv- 
er device manages the desired file according to the 
enciphered editing data received from the client 
device. 

According to another aspect of the present 

30 invention there is provided a method of file editing 
in a file editing system formed by a file manage- 
ment server device and at least one client device, 
comprising the steps of: managing files at the file 
management server device, each file containing a 

35 plurality of block data and block identification in- 
formation for each block data, and the block data 
being enciphered in units of blocks; making an 
access to the file management server device to 
obtain the block data corresponding to a desired 

40 version of a desired file managed by the file man- 
agement server device, at the client device; de- 
ciphering the block data obtained from the file 
management server device, in units of blocks by 
using a prescribed decipher key, at the client de- 

45 vice; editing the desired version of the desired file 
formed by the block data deciphered by the de- 
ciphering step, at the client device; generating ed- 
iting procedure data indicating a procedure to ob- 
tain an editing made in the desired version of the 

so desired file by the editing step, at the client device; 
converting the editing procedure data for the de- 
sired version of the desired file generated by the 
editing procedure data generating step into editing 
procedure data for a latest version of the desired 

55 file, at the client device; generating a record man- 
agement information indicating a result of the ed- 
iting made at the editing step, according to the 
editing procedure data for the latest version of the 

4 
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desired file obtained by the converting step, at the 
client device; enciphering the record management 
information generated by the record management 
information generating step, in units of blocks by 
using a prescribed cipher key, to obtain enciphered 
record management information at the client de- 
vice; and transmitting the enciphered record man- 
agement information obtained by the enciphering 
step from the client device to the file management 
server device; carrying out a record management 
of the desired file at the file management server 
device, according to the enciphered record man- 
agement information received from the client de- 
vice and the block identification information for 
each block data. 

According to another aspect of the present 
invention there is provided a method of file editing 
in a file editing system formed by a file manage- 
ment server device and at least one client device, 
comprising the steps of: managing files at a file 
management server device, each file containing a 
plurality of block data and block identification in- 
formation for each block data; making an access to 
the file management server device to obtain the 
block, data corresponding to a desired version of a 
desired file managed by the file management serv- 
er device, at the client device; deciphering the 
block data obtained from the file management serv- 
er device, by using a prescribed decipher key, at 
the client device; editing the desired version of the 
desired file formed by the block data deciphered 
by the deciphering step, at the client device; gen- 
erating editing procedure data indicating a proce- 
dure to obtain an editing made in the desired 
version of the desired file by the editing step and 
including insertion data to be inserted into the 
desired file, at the client device; enciphering the 
insertion data included in the editing procedure 
data generated by the editing procedure data gen- 
erating step, by using a prescribed cipher key, to 
obtain enciphered editing procedure data at the 
client device; transmitting the enciphered editing 
procedure data obtained by the enciphering step 
from the client device to the file management serv- 
er device; converting the enciphered editing proce- 
dure data for the desired version of the desired file 
received from the client device into enciphered 
editing procedure data for a latest version of the 
desired file, at the file management server device; 
generating record management information indicat- 
ing a result of the editing made by the editing step, 
according to the enciphered editing procedure data 
for the latest version of the desired file obtained by 
the converting step, at the file management server 
device; and carrying out a record management of 
the desired file at the file management server de- 
vice, according to the record management informa- 
tion obtained by the record management informa- 
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tion generating step and the block identification 
information for each block data. 

According to another aspect of the present 
invention there is provided a method of shared file 
5 editing in a shared file editing system formed by a 
file management server device and a plurality of 
client devices, comprising the steps of: managing 
files at the file management server device, each file 
containing a plurality of block data and block iden- 

10 tification information for each block data; making an 
access to the file management server device to 
obtain the block data corresponding to a desired 
version of a desired file managed by the file man- 
agement server device, at each client device; ed- 

75 iting the desired file formed by the block data 
obtained from the file management server device, 
at each client device; generating editing procedure 
data indicating a procedure to obtain an editing 
made in the desired file by each client device at 

20 the editing step; converting the editing procedure 
data for the desired version of the desired file 
generated at the editing procedure data generating 
step into editing procedure data for a latest version 
of the desired file; and generating record manage- 

25 ment information indicating a result of the editing 
made in the desired file by each client device at 
the editing step, according to the editing procedure 
data for the latest version of the desired file ob- 
tained by the converting step, such that the file 

30 management server device manages the desired 
file according to the record management informa- 
tion and the block identification information for 
each block data. 

Other features and advantages of the present 

35 invention will become apparent from the following 
description taken in conjunction with the accom- 
panying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

40 

Fig. 1 is a schematic diagram of an overall 
configuration of the first embodiment of a shared 
file editing system according to the present inven- 
tion. 

45 Fig. 2 is a diagram for explaining a file data 

structure in a difference pile up scheme that can 
be used in the system of Fig. 1 as a record 
management scheme. 

Fig. 3 is a diagram for explaining a file data 

so structure in an RCS scheme that can be used in 
the system of Fig. 1 as a record management 
scheme. 

Fig. 4 is a diagram for explaining a file data 
structure in a modified SCCS scheme that can be 
55 used in the system of Fig. 1 as a record manage- 
ment scheme. 

Fig. 5 is a block diagram of an asynchronous 
editing system to be incorporated into the system 

5 
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of Fig. 1. 

Fig. 6 is a diagram for explaining a manner of 
record management in the asynchronous editing 
system of Fig. 5 for a case of using the difference 
pile up scheme of Fig. 2. 

Fig. 7 is a diagram for explaining a manner of 
record management in the asynchronous editing 
system of Fig. 5 for a case of using the modified 
SCCS scheme of Fig. 4. 

Fig. 8 is a diagram for explaining an OFB 
mode stream cipher scheme that can be used in 
the system of Fig. 1 as a file data cipher scheme. 

Fig. 9 is a diagram for explaining a CFB mode 
stream cipher scheme that can be used in the 
system of Fig. 1 as a file data cipher scheme. 

Fig. 10 is a diagram for explaining a cipher 
procedure in the system of Fig. 1 at a time of block 
data division. 

Fig. 1 1 is a flow chart of a cipher procedure in 
the system of Fig. 1 at a time of block data division 
for a case of using the first cipher scheme. 

Fig. 12 is a flow chart of a cipher procedure in 
the system of Fig. 1 at a time of block data division 
for a case of using the second cipher scheme. 

Fig. 13 is a block diagram of a first exemplary 
configuration in the second embodiment of a 
shared file editing system according to the present 
invention. 

Fig. 14 is a block diagram of a shared file 
editing unit in the system of Fig. 13. 

Fig. 15 is a block diagram of a cipher unit in 
the system of Fig. 13. 

Fig. 16 is a block diagram of a second exem- 
plary configuration in the second embodiment of a 
shared file editing system according to the present 
invention. 

Fig. 17 is a block diagram of a shared file 
editing unit in the system of Fig. 16. 

Fig. 18 is a block diagram summarizing main 
features in the first exempary configuration of Fig. 
13. 

Fig. 19 is a block diagram summarizing main 
features in the second exempary configuration of 
Fig. 16. 

Fig. 20 is a block diagram of the third embodi- 
ment of a shared file editing system according to 
the present invention. 

Fig. 21 is a block diagram of a shared file 
editing unit in the system of Fig. 20. 

Fig. 22 is a block diagram of a merge process- 
ing unit in the system of Fig. 20. 

Fig. 23 is a block diagram of the fourth em- 
bodiment of a shared file editing system according 
to the present invention. 

Fig. 24 is a block diagram of a cipher unit in 
the system of Fig. 23. 

Fig. 25 is a block diagram of the fifth embodi- 
ment of a shared file editing system according to 



the present invention. 

Fig. 26 is a block diagram of a client counting 
unit in the system of Fig. 25. 

Fig. 27 is a diagram for explaining an exem- 
5 plary data structure for a count memory unit in the 
client counting unit of Fig. 26. 

Fig. 28 is a flow chart for an operation of a 
deletion request processing unit in the client count- 
ing unit of Fig. 26. 
io Fig. 29 is a flow chart for an operation of an 

editing end processing unit in the client counting 
unit of Fig. 26. 

Fig. 30 is a flow chart for a deletion command 
execution processing by a record management unit 
75 in the system of Fig. 25 for a case of using the 
difference pile up scheme of Fig. 2. 

Fig. 31 is a flow chart for a deletion command 
execution processing by a record management unit 
in the system of Rg. 25 for a case of using the 
20 RCS scheme of Fig. 3. 

Rg. 32 is a flow chart for a deletion command 
execution processing by a record management unit 
in the system of Rg. 25 for a case of using the 
modified SCCS scheme of Fig. 4. 
25 Fig. 33 is a block diagram of the sixth embodi- 

ment of a shared file editing system according to 
the present invention. 

Rg. 34 is a flow chart for an operation of a 
block data reconstruction unit in the system of Fig. 
30 33 during a deletion command execution process- 
ing in the system of Rg. 33 for a case of using the 
difference pile up scheme of Rg. 2. 

Rg. 35 is a flow chart for an operation of a 
record management unit in the system of Fig. 33 
35 during a deletion command execution processing 
in the system of Fig. 33 for a case of using the 
difference pile up scheme of Rg. 2. 

Rg. 36 is a flow chart for an operation of a 
block data reconstruction unit in the system of Fig. 
40 33 during a deletion command execution process- 
ing in the system of Fig. 33 for a case of using the 
RCS scheme of Fig. 3. 

Rg. 37 is a flow chart for an operation of a 
record management unit in the system of Fig. 33 
45 during a deletion command execution processing 
in the system of Rg. 33 for a case of using the 
RCS scheme of Fig. 3. 

Rg. 38 is a block diagram of the seventh 
embodiment of a shared file editing system accord- 
so ing to the present invention. 

Rg. 39 is a flow chart for an operation of a 
difference information construction unit in the sys- 
tem of Fig. 38 for a case of using the modified 
SCCS scheme of Fig. 4. 
55 Rg. 40 is a block diagram of the eighth em- 

bodiment of a shared file editing system according 
to the present invention. 
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Fig. 41 is a block diagram of the ninth embodi- 
ment of a shared file editing system according to 
the present invention. 

Fig. 42 is a block diagram of the tenth embodi- 
ment of a shared file editing system according to 
the present invention. 

Fig. 43 is a diagram of an exemplary access 
record list used by an access information memory 
unit in the system of Fig. 42. 

Fig. 44 is a block diagram of the eleventh 
embodiment of a shared file editing system accord- 
ing to the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Now, the first embodiment of a shared file 
editing system according to the present invention 
will be described in detail. 

This shared file editing system of the first 
embodiment incorporates two independently realiz- 
able features of the present invention. The first 
feature concerns with a provision for making it 
impossible to read out file contents from a file 
server in a shared file editing system which man- 
ages files in blocks, while the second feature con- 
cerns with a provision for making it possible to 
carry out the asynchronous editing operation in a 
shared file editing system which supports the file 
version management. 

In this First embodiment, the shared file editing 
system has a general configuration as shown in 
Fig. 1, which comprises one or a plurality of access 
requesting clients 101 (referred hereafter simply as 
clients) which issue file access requests with re- 
spect to shared files, and a file management server 
110 (referred hereafter simply as a server) for 
carrying out the management of the files and the 
communication of requested data with respect to 
the clients 101. Here, between each client 101 and 
the server 110, there is provided a communication 
path 111 for transmitting and receiving request 
messages and response messages. 

Here, the client 101 is an abstraction of a 
concept encompassing a user who issued the ac- 
tual access request, a process on a computer used 
by that user, etc. Also, as shown in Fig. 1, each 
client 101 is equipped with a cipher unit 112 for 
carrying out the enciphering and deciphering oper- 
ations. As will be described in detail below, this 
cipher unit 112 further includes an enci- 
pher/decipher processing unit for executing the ci- 
pher algorithm, and a key memory unit for storing 
a cipher key and a decipher key. Further details 
concerning functions of these encipher/decipher 
processing unit and the key memory unit will be 
described later on. 
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On the other hand, the server 110 may be a 
process on a computer for carrying out the file 
management, or an independent device having the 
file management function. 
5 The communication path 111 can be any me- 

dia which can exchange messages electronically, 
such as public network, LAN, Ethernet, or commu- 
nication using sockets within a computer 

The server 110 is managing a plurality of files 
10 113. Here, the files 113 contain not just data which 
represent the file contents, but also an information 
for record management, a list of user names for 
whom the accesses are allowed, an information 
utilized in encipher/decipher processing, etc. which 
75 will be described in detail later on. These files 113 
are enciphered in a format which can be deci- 
phered only by the respective proper clients 101. 

In a case of utilizing a usual cipher scheme in 
which the cipher key and the decipher key are 
20 identical, the proper client 101 possesses that iden- 
tical key, by means of which the files 113 can be 
enciphered or deciphered. 

Now, the file 113 has a property that its content 
is changing from time to time as a result of the 
25 editing operations such as writing and deleting 
carried out at times of accesses, even though its 
file name itself remains unchanged. For this rea- 
son, there are cases in which it is necessary to 
store the file content of the file 113 at some se- 
30 lected timings, so as to be able to cope with a later 
request for reproducing a state of the file 113 at a 
desired one of the selected timings. This type of 
request is quite common in a case of the program 
development. 

35 The most primitive scheme for realizing such a 

record management (version management) is to 
store the entire file content at each selected timing. 
However, the difference (discrepancy) between dif- 
ferent versions is rather little in general, so that this 

40 primitive management scheme is wasteful in terms 
of file sizes. Consequently, a scheme such as the 
SCCS (Source Code Control System) and the RCS 
(Revision Control System) which only stores an 
information on difference is usually employed. 

45 In the following, the outline of the data struc- 

ture in each record management scheme will be 
described. 

First, a scheme that can be considered as a 
prototype of the RCS will be explained. Here, this 

so scheme will be referred as a difference pile up 
scheme. A file data structure in this difference pile 
up scheme is shown in Fig. 2. In this scheme, the 
file in the first version at a time of its creation is 
stored in its entirety, and set as the version V. 1 

55 (block 201). Next, when a new version V. 2 is 
created by deleting a part of the version V. 1 or 
inserting something to the version V. 1, a dif- 
ference between the version V. 2 and the version 

7 
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V. 1 is obtained, and only the obtained difference 
V. 2 - V. 1 (block 202) is stored. Here, the dif- 
ference between versions is a set of data indicating 
facts such as "what is inserted where" and "from 
where to where is deleted" as provided by the 
"diff" command of the UNIX for example. The 
change encompassing the entire file is scarcely 
made, so that the size of the difference is smaller 
than the size of the entire file in general. The data 
in such a stored state, i.e., the data for the version 
V. 1 and the data for the difference V. 2 - V. 1 , can 
provide sufficient information for restoring the ver- 
sion V. 2. 

Subsequently, the difference between a new 
version after the editing and the latest stored ver- 
sion, such as the difference V. 3 - V. 2 (block 203) 
between the versions V. 3 and V. 2, the difference 
V. 4 - V. 3 (block 204) between the versions V. 4 
and V. 3, etc. is obtained each time, and only the 
difference is additionally stored in a similar manner. 

Consequently, in this difference pile up 
scheme, in order to restore the latest version (cur- 
rent version), it is necessary to utilize the records 
of all the versions complied up until then, but there 
is a significant improvement in terms of file sizes. 

Next, the RCS scheme will be explained. A file 
data structure for record management in this RCS 
scheme is shown in Fig. 3. In this RCS scheme, 
the records are managed as follows. First, the 
current version (block 304) is always stored in its 
entirety. In Fig. 3, a case in which the current 
version is version V. 4 is shown. Then, the version 
V. 3 which is immediately previous to the version 
V. 4 is stored in a format of the difference V. 3 - V. 
4 (block 303) with respect to the version V. 4. This 
scheme is characterized by taking the difference 
with reference to a timewise newer version in this 
manner. Thus, for the versions before the version 
V. 3, the difference V. 2 - V. 3 (block 302) and the 
difference V. 1 - V. 2 (block 301) are stored simi- 
larly. In this state, in a case of storing a new 
version V. 5, a processing for obtaining the dif- 
ference V. 4 - V. 5 and a processing for storing the 
obtained difference and the new version V. 5 will 
be executed. 

When this data structure is utilized, there is an 
advantage that the current version can be taken out 
easily. On the other hand, a case of restoring the 
older version is going to require a longer time, but 
usually a newer version is going to be more fre- 
quently accessed, so that this scheme is in confor- 
mity with the general manner of usage. 

Next, a scheme in which another representative 
record management scheme known as the SCCS 
scheme is modified will be explained. This is a 
version management scheme to memorize, in cor- 
respondence to each block data, an information 
indicating in which version that block data has been 
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inserted and an information indicating in which ver- 
sion that block data has been deleted. 

An exemplary file data structure for record 
management in this modified SCCS scheme is 

5 shown in Fig. 4. In the SCCS scheme, instead of 
storing the file data at a certain timing in its en- 
tirety, the file is managed in terms of blocks, and in 
a case of the insertion, a block of an inserted size 
from an inserted position is created. Here, each 

10 block is associated with two data fields 406 and 
407, where a field 406 indicates a creation timing 
or a version number at a timing of the creation of 
each block (which serves as an example of in- 
formation for identifying a creation timing of each 

75 block), and a field 407 indicates a deletion timing 
or a version number at a timing of the deletion of 
each block (which serves as an example of in- 
formation for identifying a deletion timing of each 
block). 

20 These two data fields 406 and 407 are just an 

example of a block identification information, which 
is an information to be attached in order to facilitate 
the comprehension of a positioning of individual 
block. Even in the difference pile up scheme or the 

25 RCS scheme described above, the block identifica- 
tion information has been given in a form of a tag 
such as "difference V. X - V. Y" has been attached 
to the individual block. In other words, the block 
identification information is an information indicat- 

30 ing a relationship among blocks. 

More specifically, as shown in Fig. 4, an exem- 
plary file in this modified SCCS record manage- 
ment scheme comprises four different versions V. 
1 to V. 4 for instance, and this file currently has 

35 five blocks including b1 (block 401), b2 (block 
402), b3 (block 403), b4 (block 404), and b5 (block 
405). 

Then, by referring to the contents of the two 
data fields 406 and 407 described above, it is 
40 possible to see that this file has been edited as 
follows. 

First, in the version V. 1 (first version), this file 
comprised two blocks b2 and b3. Then, in the 
version V. 2, blocks b2 and b4 were added at a top 

45 and a bottom of the file, respectively, so that this 
file in the version V. 2 comprised four blocks b1, 
b2, b3, and b4. Next, in the version V. 3, a portion 
of the block b4 was changed and rewritten as the 
block b5. In this case, the block b4 is attached with 

50 a flag indicating that it was deleted in the version 
V. 3, and the record management to indicate that 
the block b5 was inserted is newly made imme- 
diately below the block b4. Consequently, this file 
in the version V. 3 comprised four blocks b1, b2, 

55 b3, and b5. Then, in the version V. 4 (current 
version), the block b2 was deleted so that the block 
b2 is attached with a flag indicating that it was 
deleted in the version V. 4 accordingly. Conse- 
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quently, this file in the version V. 4 comprises three 
blocks b1, b3, and b5. Note that, before the version 
V. 4, the blocks b2 and b3 have been a single 
block, but in the version V. 4, a first half of that 
block corresponding to the block b2 was deleted. 

As can be seen in the above example, in the 
modified SCCS record management scheme, the 
file in the current version does not exist as a 
continuous set, but any version can be taken out 
by connecting those blocks which had been cre- 
ated in that version or earlier versions and which 
had not been deleted by the time of that version, in 
an order from top to bottom, so that it is character- 
ized by the fact that any version can be taken out 
without loading too much. Also, it can be seen that 
there is a tendency for blocks to be further divided 
as the version progresses. Thus, in this modified 
SCCS scheme, the record management can be 
realized easily as long as it is possible to specify 
the position of the block to be inserted and a range 
to be deleted together. 

Now, in the shared file editing system of this 
first embodiment, the cipher technique is utilized in 
order to provide a protection for the reading of the 
file content. In this respect, the first feature of the 
present invention is characterized by that fact that 
it does not allow the server which is storing the file 
itself to read out file content, while the second 
feature of the present invention is characterized by 
the fact that it supports a plurality of subjects for 
carrying out the editing operation with respect to 
the file by realizing the asynchronous editing op- 
eration without using the exclusive actions such as 
locking as much as possible. Then, by combining 
the file data structure as described above with this 
cipher feature, it becomes possible to realize the 
shared file editing system in which the secrecy of 
the file content with respect to the server can be 
secured while the asynchronous editing operation 
by a plurality of subjects can be realized by utiliz- 
ing the above described file data structure. 

In the following, the feature concerning the 
asynchronous editing without using the locking will 
be described. In realizing the asynchronous editing, 
the following problem must be resolved. Namely, 
suppose that a certain client A has read out the file 
in the current version V. 4, and created a new 
version V. A by carrying out partial deletion and 
insertion with respect to the read out version, while 
almost at the same time, another client B has also 
read out the file in the current version V. 4 at that 
timing and created a new version V. B by carrying 
out partial deletion and insertion with respect to the 
read out version. Then, assume that the write-back 
of the editing made by the client A was executed 
before the write-back of the editing made by the 
client B. In such a case, the version V. A is going 
to be stored as a new version V. 5 and the neces- 
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sary record management is going to be carried out, 
but then the write-back of the version V, B can give 
rise to a contradiction. That is, if the version V. B is 
stored as a still newer version V. 6, the latest 

5 version V. 6 is not going to reflect the changes 
made in the earlier version V. 5. In order to prevent 
this problem, it is necessary for each new version 
to be always capable of merging all the changes 
that have been made up to then. 

io In order to realize this type of asynchronous 

editing, the shared file editing system of this first 
embodiment utilizes the record management as 
follows. Namely, the attention is paid to the fact 
that every editing action can be described as some 

75 combination of deletion and insertion, and this de- 
scription can be determined uniquely as a dif- 
ference with respect to the editing target version. 
With this fact in mind, one editing action E1 can be 
defined as a set A1 of editing procedures for 

20 inserting what to where and deleting from where to 
where with respect to the version V. 4, while an- 
other editing action E2 can be defined similarly as 
a set A2 of other editing procedures with respect to 
the same version V. 4. 

25 Then, when the write-back of the editing action 

E1 is to be made first, the new version V. 5 is 
created by storing the editing procedures A1 as a 
difference with respect to the editing target version 
V. 4 in a format suitable for the record rnanage- 

30 ment scheme. Then, when the write-back of the 
editing action E2 is to be made, the editing proce- 
dures A2 which specify a difference with respect to 
the editing target version V. 4 are converted into 
converted editing procedures A2* which specify a 

35 difference with respect to the latest version V. 5, 
and the new version V. 6 is created by storing 
converted editing procedures A2* as a difference 
with respect to the previous version V. 5 in a 
format suitable for the record management 

40 scheme. By repeating this operation, it is possible 
to realize the asynchronous editing without any 
contradiction. 

Here, what is important is to convert the editing 
procedures which are originally not defined as a 

45 difference with respect to the current version into a 
difference with respect to the current version with- 
out any contradiction. This mechanism can also be 
utilized to support an operation for carrying out the 
editing with respect to much older version, and 

50 merging the result of that editing with the current 
version. 

Now, a configuration of an asynchronous ed- 
iting system for realizing the above described op- 
eration will be described with reference to Fig. 5. In 
55 this Fig. 5, the asynchronous editing system com- 
prises an editing unit 500, an editing procedure 
generation unit 501, an editing procedure conver- 
sion unit 502, a record management information 
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generation unit 503, a record management unit 
510, and a data memory unit 511. Note that this 
asynchronous editing system is to be distributed 
over the server 110 and the client 101 as described 
in the second embodiment, and a manner of dis- 
tributedly arranging the elements of this system is 
to be set according to whether or not to utilize the 
ciphering of the file, although the editing unit 500 
will be implemented on the client 101 and the data 
memory unit will be implemented on the server 
110 in any case. 

The editing unit 500 carries out the editing with 
respect to the file content in the editing target 
version obtained from the record management unit 
510. 

The editing procedure generation unit 501 re- 
ceives the file content in the editing target version 
and the file content resulting from the editing car- 
ried out with respect to that file by the editing unit 
500, and generates editing procedure data includ- 
ing insertion data, insertion positions, deletion start 
positions, and deletion end positions, which in- 
dicate "what is inserted where" and "from where to 
where is deleted". 

The editing procedure conversion unit 502 re- 
ceives these editing procedure data and record 
data described below, and generates the editing 
procedure data converted into the editing proce- 
dures with respect to the current version. For ex- 
ample, for given editing procedure data, the inser- 
tion data are left unchanged, while the insertion 
positions are converted into corresponding posi- 
tions with respect to the current version, and the 
deletion start positions and the deletion end posi- 
tions are similarly converted into corresponding 
positions with respect to the current version. In this 
conversion operation, the record data supplied from 
the record management unit 510 are utilized as 
necessary supplementary input. 

The record management unit 510 carries out 
the management of the record data stored as an 
updating record of the editing target file. The ed- 
iting procedure data outputted from the editing 
procedure conversion unit 502 are entered into the 
record management information generation unit 
503 and converted into the record data in a format 
suitable for the record management scheme used 
by this record management information generation 
unit 503, and these record data are sent to the 
record management unit 510, so as to carry out the 
updating of the latest version. 

The data memory unit 511 stores the file con- 
tents of a plurality of files. 

Next, the operation of each element in this 
asynchronous editing system shown in Fig. 5 will 
be described for specific record management 
schemes. In any case, the editing procedure gen- 
eration unit 501 carries out the operation corre- 



sponding to the "diff" command of the UNIX. 
Namely, the editing procedure generation unit 501 
compares the file data in the editing target version 
and the file data after the editing, and outputs the 
5 editing procedure data such as "what is inserted 
where" and "from where to where is deleted". 

Hrst, a case of using the difference pile up 
scheme of Fig. 2 described above as the record 
management scheme will be described with refer- 
70 ence to an exemplary situation depicted in Fig. 6. 

In this example, the editing target version is the 
version V. 2 and the current version is the version 
V. 4. Then, it is assumed that the output A1 of the 
editing procedure generation unit 501 is as follows. 
is * i4 

Newly inserted from here. 
Can it be merged well? 
* d8, 9 

This output indicates that, with respect to the 
20 version V. 2, two lines ("Newly inserted from here." 
and "Can it be merged well?") are inserted at the 
line 4, and two lines from the line 8 to the line 9 
are deleted. 

The editing procedure conversion unit 502 
25 functions to convert the above described editing 
procedure A1 into the editing procedure AV with 
respect to the current version V. 4. In this conver- 
sion, the record data from the record management 
unit 510 indicating the past records of editing made 
30 from the version V. 2 to the current version V. 4 are 
necessary. 

As an example, suppose that the version V. 3 
deleted the line 2 and the line 3 of the version V. 2 
and inserted one line ("This is line 5 of V. 2.") at 

35 the line 5 of the version V. 2, while the version V. 4 
deleted the line 5 to the line 7 of the version V. 3 
and inserted two lines ("This part is changed this // 
way as I didn't like it." where // indicates the line 
change) at the line 8 of the version V. 3. In this 

40 case, for the insertion position in the editing proce- 
dure A1, it is necessary to determine which line of 
the current version V. 4 does the line 4 of the 
version V. 2 corresponds to. To this end, the dif- 
ference between versions V. 3 and V. 2 and the 

45 difference between versions V. 4 and V. 3 contain 
all the necessary information, and it can be recog- 
nized that the line 2 of the version V. 4 cor- 
responds to the line 4 of the version V. 2, so that 
"insert two lines at the line 4 of the version V. 2" is 

so converted into "insert two lines at the line 2 of the 
version V. 4" accordingly. Similarly, for the dele- 
tion, when the lines of the version V. 4 correspond- 
ing to the lines 8 and 9 of the version V. 2 are 
checked according to the record data, it can be 

55 recognized that the line 9 of the version V. 2 
corresponds to the line 7 of the version V. 4 but 
the line 8 of the version V. 2 had already been 
deleted in the version V. 4. The deletion of a 

10 
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portion which had already been deleted normally 
does not make sense, so that "delete the line 8 to 
the line 9 of the version V. 2" is converted into 
"delete the line 7 of the version V. 4" in this case. 
The editing procedure conversion unit 502 carries 
out the conversion of the editing procedures (main- 
ly comprising the search of the changed positions) 
as described above. Thus, the record data are 
indispensable in this editing procedure conversion 
unit 502. 

The record management information generation 
unit 503 obtains the difference between the current 
version V. 4 and the new version according to the 
editing procedure data AV so obtained and en- 
tered thereto. Here, as the difference pile up 
scheme is used as the record management 
scheme, the above mentioned "insert two lines at 
the line 2 of the version V. 4" and "delete the line 
7 of the version V. 4" are turned into the record 
data as they are, and these record data are sent to 
the record management unit 510 and added to the 
stored record. 

Next, a case of using the modified SCCS 
scheme of Fig. 4 described above as the record 
management scheme will be described with refer- 
ence to an exemplary situation depicted in Fig. 7. 
In this case, the operation for searching the 
changed positions at the editing procedure conver- 
sion unit 502 can be simplified as follows. 

Namely, suppose that the version V. 2 had 10 
lines as depicted in Fig. 7. Then, first, as the line 2 
and the line 3 of the version V. 2 are deleted in the 
version V. 3, the portion of these lines 2 and 3 
becomes one block with the deletion time flag 
indicating "V. 3". Also, as one line is inserted 
between the line 4 and the line 5 of the version V. 
2, the line 4 of the version V. 2 becomes one 
block, while one line inserted in the version V. 3 
becomes another block with the creation time flag 
indicating "V. 3". 

Next, as the line 5 to the line 7 of the version 
V. 3 are deleted in the version V. 4, the line 5 to 
the line 7 in the version V. 3 by counting only 
those lines which are not deleted at a time of the 
version V. 3 from top becomes one block with the 
deletion time flag indicating "V. 4". Also, as two 
lines are inserted between the line 7 and the line 8 
of the version V. 3, these two inserted lines forms 
one block with the creation time flag indicating "V. 
4". 

The editing procedure A1 outputted from the 
editing procedure generation unit 501 is similar to 
that described above, but the record data supplied 
from the record management unit 510 to the ed- 
iting procedure conversion unit 502 are given in a 
form of the version V. 4 in Fig. 7. Then, at the 
editing procedure conversion unit 502, in order to 
determine the line 4 (insertion position), the line 8 
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(deletion start position), and the line 9 (deletion end 
position) at a time of the version V. 2, the fourth, 
eighth, and ninth lines from the top in the version 
V. 2 are figured out. Here, the point is to skip those 
5 portions which are inserted after the version V. 2. 

To the insertion position so determined, the 
two newly inserted lines ("Newly inserted from 
there. // Can it be merged well?") are inserted as 
one block. In addition, as for the deletion, nothing 
10 is done for the line 8 of the version V. 2 as the 
deletion time flag is already set up for it, while the 
fine 9 is divided as one block with the deletion time 
flag indicating "V. 5". The version V. 5 produced in 
this manner is then sent to the record management 
75 unit 510 so as to update the stored record data. 

The record management information generation 
unit 503 accounts for the operation up to the updat- 
ing at the record management unit 510 in the 
above described sequence. 
20 As described, when a scheme such as the 

modified SCCS scheme is utilized as the record 
management scheme, the search of the changed 
positions can be achieved by the simple counting 
from the top, so that the necessary operation can 
25 be simplified considerably. 

Thus, in this first embodiment, it is possible to 
utilize the data structure of Fig. 4 for the modified 
SCCS scheme as the record management scheme, 
while realizing the asynchronous editing according 
30 to the configuration of Fig. 5 at the same time. 

Now, another feature of this first embodiment 
concerning a cipher scheme for the file data will be 
described in detail. 

The cipher scheme in this first embodiment is 
35 characterized by the fact that the file is enci- 
phered/deciphered in units of data blocks produced 
in a course of the record management as de- 
scribed above, block by block, and that the file 
structure which enables the server to comprehend 
40 which data block corresponds to which portion of 
the file is adopted. 

More specifically, as an example of such a file 
structure, in a case of using the difference pile up 
scheme of Fig. 2 as the record management 
45 scheme, each of the blocks 201 , 202, 203, and 204 
is enciphered independently and given in a form by 
which the server can recognize the correspon- 
dence relationship such as "a block 201 is the 
enciphered data of the first version V. 1 ", "a block 
so 202 is the enciphered data of the difference V. 2 - 
V. 1 between the version V. 2 and the version V. 
1", etc. As a concrete example, it is possible to 
provide a flag field for the server management to 
each block to be enciphered, and enter an appro- 
55 priate information such as V. 1 or V. 2 - V. 1 
therein, 

Such an information to be utilized by the server 
to identify each data block will be referred as the 

11 
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block identification information. The flag field for 
the server management mentioned above, and the 
data fields 406 and 407 for the creation time and 
the deletion time in Fig. 4 described above are 
examples of this block identification information. 

As another example of the file structure, in a 
case of using the RCS scheme of Fig. 3 as the 
record management scheme, each of the blocks 
301, 302, 303, and 304 is enciphered indepen- 
dently, and given in a form by which the server can 
recognize the correspondence relationship such as 
"a block 301 is the enciphered data of the dif- 
ference V. 1 - V. 2 n , "a block 302 is the enciphered 
data of the difference V. 2 - V. 3", etc. 

As still another example of this file structure, in 
a case of using the modified SCCS scheme of Fig. 
4 as the record management scheme, each of the 
blocks 401, 402, 403, and 404 is enciphered in- 
dependently, and given in a form by which the 
server can recognize the correspondence relation- 
ship such as "a block 401 is a top block, a block 
402 is a next-to-top block", etc. Here, it suffices to 
simply connect blocks such that the partitions 
among the block become apparent. Each block in 
Fig. 4 has two data fields 406 and 407 for the 
creation time and deletion time in correspondence 
as mentioned above, but these data fields are not 
to be enciphered. 

This manner of enciphering each block inde- 
pendently has an advantage that the amount of 
processing required in the client and the amount of 
communication between the client and the server. 
Namely, when the client makes a request for the 
current version to the server in the record manage- 
ment system of Fig. 3, it suffices for the server to 
transmit the enciphered block 304 alone. In con- 
trast, if the entire data file of Fig. 3 is enciphered 
together, it would be necessary for the server to 
transmit the entire enciphered data, and in addition, 
it would also be necessary for the client who re- 
ceived this transmitted data to decipher all the 
blocks 301 to 304 which are enciphered together, 
so that many otherwise unnecessary processings 
would become necessary. 

Also, in the record management scheme of 
Fig. 2, only change that can be made by the client 
side as a result of a new editing action is an 
addition of an enciphered block for the difference 
V. 5 - V. 4. In such a case, if the entire file is 
enciphered together, it would be particularly dif- 
ficult to verify that a portion near the partition with 
respect to the difference V. 4 - V. 3 has not been 
changed. Namely, the enciphering is usually made 
from a top of the file in a form of a chain of certain 
lengths dividing the file, so that it is possible for the 
server to conjecture the occurrence of an action to 
change a portion other than that near the end of 
the file from the cipher text, but such a detection of 



a change cannot be made at a portion near the end 
of the file (i.e., a portion near the newly added 
difference). In contrast, when the enciphering in 
units of blocks as described above is adopted for 

5 the data structure of Fig. 2, it suffices to sequen- 
tially add the enciphered data for a new difference, 
so that the server can easily carry out the manage- 
ment to prevent the change of the records. 

In view of realizing the asynchronous editing 

io without locking described above, it is particularly 
suitable to use the record management scheme 
using the data structure of Fig. 4 even from a point 
of view of the simplification of the merge process- 
ing. However, this type of record management 

75 scheme has a characteristic that the block which 
had been a single entity at one time is going to be 
subdivided sequentially at subsequent times. In 
general, in conjunction with the division of a block, 
there arises a need to re-encipher the block data, 

20 and for this reason, this first embodiment employs 
the cipher scheme capable of reducing the enci- 
pher/decipher processing, which will now be ex- 
plained in detail. 

The data within each block can be considered 

25 as given by bits or bytes as minimum units, and in 
the first cipher scheme for this first embodiment 
described below, in a case of dividing one block at 
several positions (point- 1 , point-2, and so on, in an 
order from the top of the block), it is unnecessary 

30 to re-encipher the enciphered data from the top of 
the block to the point-1 and the already enciphered 
data can be utilized as they are, so that only the 
data after the point-1 need to be re-enciphered. 
Moreover, in the second cipher scheme for this 

35 first embodiment described below, there is ab- 
solutely no need to re-encipher any data and the 
already enciphered data can be utilized as they 
are. 

In order to make such a re-utilization of the 

40 already enciphered data possible, the cipher 
scheme is required to satisfy the following con- 
dition. Namely, in a case the cipher block is di- 
vided at an arbitrary point, it must be possible to 
obtain the corresponding plain text from a fragment 

45 of that divided cipher block. Consequently, it is 
necessary to have a particular bit (or byte) of the 
plain text to be in correspondence to a particular 
bit (or byte) of the cipher text. As a natural con- 
sequence of that, there should not be a size in- 

50 crease due to the enciphering. As a cipher scheme 
with such a property, a scheme called stream 
cipher scheme is known, and a representative ex- 
ample of this scheme, there is a scheme for using 
the block cipher DES (Data Encryption Standard) in 

55 either the OFB (Output FeedBack) mode or the 
CFB (Cipher FeedBack) mode. The cipher proce- 
dure in the OFB mode is shown in Fig. 8, while the 
cipher procedure in the CFB mode is shown in Fig. 

12 
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9. 

First, with reference to Fig. 8, the operation 
principle in the OFB mode will be described. In this 
case, the transmitting side and the receiving side 
share a key K for the block cipher devices 603 and 
613 and an initial value IV for shift registers 602 
and 612 to be set in initial value registers 601 and 
611. 

At a time of enciphering, the transmitting side 
enciphers a content of the shift register 602 by the 
block cipher device 603, and L bits of the obtained 
cipher result in the cipher result register 604 are 
fed back to the shift register 602 while also sub- 
jected to the exclusive OR operation with respect 
to L bits of the plain text at the XOR circuit 605. By 
repeating this processing, the plain text is enci- 
phered in units of L bits. Here, even though an 
amount which is enciphered by one processing is L 
bits, the enciphering is actually made bit by bit. 

Similarly, at a time of deciphering, the receiv- 
ing side deciphers a content of the shift register 
612 by the block cipher device 613, and L bits of 
the obtained cipher result in the cipher result regis- 
ter 614 are fed back to the shift register 612 while 
also subjected to the exclusive OR operation with 
respect to L bits of the cipher text at the XOR 
circuit 615. By repeating this processing, the cipher 
text is deciphered in units of L bits. Again, even 
though an amount which is deciphered by one 
processing is L bits, the deciphering is actually 
made bit by bit. 

First, with reference to Fig. 9, the operation 
principle in the CFB mode will be described. In this 
case, the transmitting side and the receiving side 
share a key K for the block cipher devices 623 and 
633 and an initial value IV for shift registers 622 
and 632 to be set in initial value registers 621 and 
631. 

At a time of enciphering, the transmitting side 
enciphers a content of the shift register 622 by the 
block cipher device 623, and L bits of the obtained 
cipher result in the cipher result register 624 are 
subjected to the exclusive OR operation with re- 
spect to L bits of the plain text at the XOR circuit 
625, while L bits of the cipher text obtained by the 
XOR circuit 625 are fed back to the shift register 
622. 

Similarly, at a time of deciphering, the receiv- 
ing side deciphers a content of the shift register 
632 by the block cipher device 633, and L bits of 
the obtained cipher result in the cipher result regis- 
ter 634 are subjected to the exclusive OR operation 
with respect to L bits of the cipher text at the XOR 
circuit 635, while L bits of the received cipher text 
are fed back to the shift register 632. 

Thus, this case of CFB mode differs from the 
above described case of OFB mode only in that 
the data fed back to the shift register at a time of 



enciphering/deciphering are set to be the cipher 
text rather than the output of the block cipher 
device, in the transmitting side as well as in the 
receiving side. 

5 These modes are called L bit OFB mode or L 

bit CFB mode, using a number of bits utilized in 
one encipher/decipher processing (which coincides 
with a number of bits to be fed back to the shift 
register), which are representative examples of the 

to stream cipher in bit unit Similarly, the representa- 
tive examples of the stream cipher in byte unit 
include 8 bit OFB mode and 8 bit CFB mode. In 
these modes, instead of enciphering/deciphering 
by taking the exclusive OR of 8 bits of the plain 

75 text and 8 bits of the cipher device output bit by 
bit, it is also possible to modify them to use the 
enciphering/deciphering by addition/subtraction of 
8 bits, for example. 

In the following, it is assumed that the mini- 

20 mum units of the data within each block are bytes. 

In order to guarantee the strength of the cipher 
text using the stream cipher as described above, 
when the key K is fixed, it is preferable to change 
the initial value IV of the shift register for each plain 

25 text. Otherwise, the cipher text has weak points in 
that the exclusive OR of two plain texts can be 
obtained by taking the exclusive OR of the same 
position in two cipher texts, and that the two plain 
texts can be recognized as the same when two 

30 corresponding cipher texts have the identical top 
portion. For this reason, in this first embodiment, 
the initial value IV of the shift register is to be 
changed for each block to be enci- 
phered/deciphered. 

35 Now, the cipher procedure at a time of the 

block data division using the cipher scheme of this 
first embodiment will be described with reference 
to Fig. 10. In this Fig. 10, a left side of an arrow 
indicates the data structure before the block data 

40 division, and the right side of an arrow indicates the 
data structure after the block data division. Here, 
Fig. 10 depicts an exemplary case in which a 
middle portion of a certain cipher block (block-0) is 
deleted, in which case this block is re-enciphered 

45 as three blocks for the top portion (block-1), the 
middle portion (block-2), and the bottom portion 
(block-3). For each block, there is provided a re- 
gion 642 for storing the initial value data IV (IV0 to 
IV2). However, this initial value data IV is not to be 

50 enciphered. 

In the first cipher scheme of this first embodi- 
ment, the L bit OFB mode or the L bit CFB mode 
is used, with L set to be a multiple of 8. The initial 
value data IV of each block is generated by means 

55 of the random number generation at a time of a 
new block creation. The block data are enciphered 
L bits by L bits in an order from the top as 
described above. There is a case in which the end 
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of the block does not coincide with the L-th bit 
exactly, but even in such a case, the cipher is cut 
off at the length of the plain text. It is still possible 
to decipher the last portion even in such a case. 

The cipher procedure at a time of the block 
data division as shown in Fig. 10 will be described 
with reference to the flow chart of Fig. 1 1 . 

First, the top portion before the deletion start 
position is separated as one block (block- 1) as it is 
(step S1). Then, the initial value IV1 is determined 
by means of the random number generation (step 
S2), and by the OFB (or CFB) mode using this 
initial value IV!, data of the deletion portion (plain 
text corresponding to block-2) are enciphered to 
form a new block (block-2) (step S3). Next, another 
initial value IV2 is determined (step S4), and data 
of the bottom portion are enciphered to form a new 
block (block-3) (step S5). 

This cipher procedure is characterized by the 
fact that the block of the top portion utilizes the 
original initial value IVO as it is, so that there is no 
need to re-encipher this block. 

Next, the second cipher scheme of this first 
embodiment which is characterized by the fact that 
there is absolutely no need to re-encipher any data 
will be described. In this case, the 8 bit CFB mode 
is used. 

With respect to a new insertion block, the initial 
value data IV are generated by means of the ran- 
dom number generation, and the block data are 
enciphered byte by byte in an order from the top. 

The cipher procedure at a time of the block 
data division as shown in Fig. 10 will be described 
with reference to the flow chart of Fig. 12. 

First, the cipher block (block-0) is divided into 
three at individual division positions (step S11). 
Next the last 8 bytes of the block-1 are stored as 
the initial value data IV of the block-2 (step S12). 
Then, the last 8 bytes of the block-2 are stored as 
the initial value data IV of the block-3 (step S13). At 
a time of storing the initial value data IV at the 
steps S12 and S13, there can be a case in which 
the previous block is less than 8 bytes long. In 
such a case, it is necessary to employ a special 
treatment in which the previous block is regarded 
as the initial value data IV + block data, such that 
the block data can be supplemented by as many 
bytes of the initial value data IV as necessary. 

This second cipher scheme utilizes the prop- 
erty of the 8 bit CFB mode that the deciphering 
can be made from an arbitrary position, and it has 
an advantage that the re-enciphering in conjunction 
with the block division becomes totally unneces- 
sary. This advantage also implies that, in a case of 
realizing the enciphered shared file system by the 
client server system, the server without the enci- 
pher/decipher function can carry out the block di- 
vision processing, so that the efficient realization of 



the system becomes possible. It is also possible to 
expand the above cipher procedure to the general 
L bit CFB mode (with L set to be a multiple of 8), 
but the supplementary data become necessary for 

5 that purpose, because there can be a case in 
which the block-2 of Fig. 10 does not start from the 
partition at L bits from the top of the original block- 
0. The data of the block-2 are data enciphered in 
units of L bits from the top of the block-0, so that it 

10 is necessary to make it possible to reproduce the 
original partitions in units of L bits. To this end, u 
bits (u is an integer for which u ^ L) from the top of 
the block is used as the supplementary data for 
indicating that it is a fragmentary block, and at a 

15 time of deciphering, it is deciphered after the ci- 
pher text of (L-u) bits is added as a dummy at the 
top of the block data and the top (L-u) bits in the 
deciphered result are ignored. The subsequent 
data can be deciphered in units of L bits. Also, the 

20 initial value data IV to be stored at a time of the 
block division are set to be a content of 8 bytes 
immediately before the fragmentary bits (L-u bits) 
at the end of the previous block. In a case the 
previous block is too short, just as in a similar case 

25 of the 8 bit CFB mode explained above, the block 
data can be supplemented by the initial value data 
IV as much as necessary. 

In the above, a case of the block division in 
conjunction with the deletion has been described, 

30 but in a case of the insertion, it becomes as 
follows. Namely, in a case of inserting a certain 
block in a middle of already existing block, there is 
a need for a division of the already existing block 
corresponding to the procedure of Fig. 11 or Fig. 

35 12 described above, as well as for the enciphering 
of a new insertion block data. Here, the enciphering 
of a new insertion portion is made by determining 
the initial value IV by means of the random number 
generation, and then by using the OFB (or CFB) 

40 mode using this initial value IV. Also, in a case of 
inserting a certain block between already existing 
blocks, no change is necessary for the already 
existing blocks, and it suffices to encipher the new 
insertion block alone. 

45 In the following the features of the record man- 

agement scheme according to this first embodi- 
ment will be summarized. Here, the shared file 
editing system using the enciphered difference pile 
up scheme shown in Fig. 2, the shared file editing 

so system using the enciphered RCS scheme shown 
in Fig. 3, and the shared file editing system using 
the enciphered SCCS scheme shown in Fig. 4 will 
be compared. 

First, regarding the asynchronous editing func- 

55 tion without locking, the enciphered SCCS scheme 
is advantageous because the merge processing 
can be simplified as already explained above. 
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Next, regarding the take out of the current 
version, the enciphered RCS scheme is most ad- 
vantageous as it stores the current version as it is 
in a form of the enciphered data. The enciphered 
SCCS scheme is advantageous next, and it has a 5 
characteristic that an arbitrary version can be re- 
stored by the same level of processing. 

Next, in view of a case in which it is desired to 
delete the old records in order to compress the file 
size, the enciphered RCS scheme and the enci- w 
phered SCCS scheme are both superior. This is 
because, in these schemes, the server which re- 
ceived a request to this end can delete the records 
by itself. In the enciphered difference pile up 
scheme, the old records can be deleted by an 75 
interaction from the client. 

Here, it should be noted that, in a case of the 
enciphered SCCS scheme, the fusion of the blocks 
does not takes place even when the old records 
are deleted, and only the separation of the unnec- 20 
essary blocks is carried out In a case of carrying 
out the fusion of the blocks as well, the interaction 
from the client becomes necessary. Also, it should 
be noted that, in the enciphered RCS scheme, 
what the server can do by itself is to delete the 25 
records in an order from the older side. 

It is preferable to manage the record content to 
be not changed later on, and regarding such a 
completeness of the record content, the enciphered 
difference pile up scheme is superior. As explained 30 
earlier, the client is only allowed to sequentially 
add differences in this scheme, so that the com- 
pleteness of the records can be guaranteed. 

As described above, by applying one or both 
of the characteristic features of this first embodi- 35 
ment, it becomes possible to provide a shared file 
editing system which supports the file version man- 
agement, which is capable of realizing the asyn- 
chronous editing while keeping the file contents 
secret from the file server, or a shared file editing 40 
system which supports the file version manage- 
ment, which is capable of realizing the asynchro- 
nous editing, or a file editing system capable of 
realizing a higher level of secrecy such that the file 
contents cannot be read out from the file server. 45 

In the above, in enciphering the structured 
files, the data content is enciphered such that only 
the client can encipher/decipher it, but the data 
structure in a format that can also be recognized 
by the server has been shown, and in particular, 50 
the applications to the version management and 
the asynchronous editing have been described. 
The present invention is applicable to various other 
systems and schemes, such as a scheme for enci- 
phering the program in units of sub-routines, and a 55 
scheme for dealing with a plurality of data files 
which are linked together as in the hypertext, in 
which the data files are enciphered in units of data 



files and linked portions are not enciphered. In this 
manner, it becomes possible to realize an efficient 
manner of utilization in which the client can read 
out only the necessary portion while maintaining 
the secrecy of the module content with respect to 
the server. 

Next, the second embodiment of a shared file 
editing system according to the present invention, 
in which the above described first feature concern- 
ing the file content secrecy with respect to the 
server and the above described second feature 
concerning the asynchronous editing are imple- 
mented on the client server type system will be 
described in detail. 

In this second embodiment, the individual fea- 
tures related to the file structure, the record man- 
agement scheme, the cipher scheme, and the 
asynchronous editing system are basically the 
same as those for the first embodiment described 
above, and their detailed descriptions will not be 
repeated here. In the following, the configuration 
and the operation characteristic to this second em- 
bodiment will be described. 

Fig. 13 shows a first configuration of the shared 
file editing system of this second embodiment, 
which generally comprises a plurality of clients 91 
and a server 90. 

The server 90 further comprises a communica- 
tion (COMM) unit 131 for carrying out a commu- 
nication with each client 91 through a communica- 
tion path 111, a record management unit (for 
shared file) 510 for managing records for shared 
files, and a data memory unit 511 for storing a 
plurality of files, where the record management unit 
510 and the data memory unit 511 correspond to 
the record management unit 510 and the the data 
memory unit 51 1 in the asynchronous editing sys- 
tem of Fig. 5 described above. 

On the other hand, each client 91 further com- 
prises a communication (COMM) unit 130 for carry- 
ing out a communication with the server 90 through 
the communication path 111, a memory 121 for 
storing files obtained from the server 90, a shared 
file editing unit 122 for editing the shared files, and 
a cipher unit 112 for enciphering/deciphering the 
files. 

As shown in Fig. 14, the shared file editing unit 
122 includes the editing unit 500, the editing proce- 
dure generation unit 501, the editing procedure 
conversion unit 502, and the record management 
information generation unit 503 corresponding to 
those in the asynchronous editing system of Rg. 5 
described above. 

As shown in Fig. 15, the cipher unit 112 in- 
cludes a communication (COMM) unit 132 con- 
nected with the shared file editing unit 122, an 
encipher/decipher processing unit 1121 connected 
with the communication unit 132, and a key mem- 
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ory unit 1122 connected with the encipher/decipher 
processing unit 1121. 

Now, as a plurality of clients 91 are provided in 
this second embodiment, requests for the following 
three types of operations occur at various timings: 5 

(a) a reading of file data of a particular version 
(arrow from 510 to 500 in Fig. 5); 

(b) a writing of a record management informa- 
tion which is an editing result (arrow from 503 to 

510 in Fig. 5); and io 

(c) a reading of record data necessary in con- 
verting the editing procedure (arrow from 510 to 
502 in Fig. 5). 

Here, a general procedure for dealing with 
these requests in this second embodiment will be is 
described. 

As described before, the editing procedure cor- 
responding to one record management information 
comprises a combination of a plurality of insertions 
and deletions, and it is preferable to handle them 20 
together. That is, when a certain client 91 made 
changes at a plurality of positions in the file of a 
certain version, a new version is made at a timing 
at which all these changes are reflected in the data 
on the server 90 side. The write requests for the 25 
record management information are set in a queue 
one by one, and sequentially reflected into the file 
data as they are sequentially taken out by the 
record management unit 510 in First-in-First-out 
manner. Here, the record management unit 510 30 
responds to the read requests ((a) and (c) men- 
tioned above) from the client 91 whenever neces- 
sary, but in a case the read request for the current 
version of one file arrives during the updating of 
the file data for the same file at the record manage- 35 
ment unit 510, there is a need to transmit the 
version before the updating. 

The client 91 requests the data of a certain 
version (version X) from the server 90 initially, and 
after storing the data in the memory 121, the 40 
editing is carried out at the editing unit 500, and 
the editing procedure data are generated at the 
editing procedure generation unit 501. In a case 
the version X is the latest version at a time of 
reading, the editing procedure is not converted and 45 
the record management information is generated 
immediately, and subsequently enciphered and 
transmitted to the server 90. At the receiving server 
90 side, whether it is the record management in- 
formation that can be merged with the latest ver- 50 
sion at that timing or not is judged, and if it cannot 
be merged, the record data are transmitted from 
the record management unit 510 to the client 91, to 
request the conversion of the editing procedure at 
the editing procedure conversion unit 502. 55 

Here, the judgment as to whether it can be 
merged or not can be made by attaching a version 
number of the target data to a header of the record 



management information to be transmitted at the 
client 91 side, such that the server 90 side can 
compare the version number in the header with the 
version number of the latest version stored therein, 
and judge that it can be merged when they co- 
incide, and that it cannot be merged otherwise. In 
addition, the record data to be transmitted to the 
client 91 when it cannot be merged can be the 
record data between the latest version and the 
version indicated by the version number in the 
header of the record management information for 
example. At the client 91 side, the prescribed ed- 
iting procedure conversion is carried out to gen- 
erate a new record management information, and 
this is sent to the server 90 again, such that the 
server 90 side judges whether it can be merged or 
not again. 

Here, there is a possibility that the new record 
management information cannot be merged again. 
Namely, it is a case where the file version has 
been updated by the other client during the editing 
procedure conversion processing at this client 91. 
Consequently, there is a possibility for circulating 
through the loop of 510 — 502 —503 in Fig. 5 
many times. 

In order to prevent such a repetitive process- 
ing, it is possible to utilize the lock function. Name- 
ly, at a timing at which the record data are trans- 
mitted to the client 91 , the server 90 side sets the 
lock on the updating of the file data, and releases 
the lock at a timing at which the updating of the file 
data is completed after the record management 
information is received from that client 91. While 
the lock is set, the reading of the editing target file 
data is permitted, but the other processing is re- 
jected at the server 90 side. The other client 91 
whose request has been rejected will make a re-try 
after an appropriate amount of time. Here, the 
waiting period due to this lock mechanism can be 
considered as very short, but this lock mechanism 
is not absolutely necessary. 

On the other hand, in a case the version X 
initially read out from the server 90 is not the latest 
version at a time of reading, for the purpose of the 
processing at the editing procedure conversion unit 
502, the record data from that version X to the 
latest version are requested to the server 90. 
Thereafter, the operation similar to that already 
described above is carried out. 

In the above procedure, the editing target file 
and the record data received by the client 91 and 
the record management information transmitted to 
the server 90 are all enciphered in units of struc- 
tural units, and they are enciphered/deciphered by 
means of the cipher unit 112. 

In this manner, in this second embodiment, the 
file content can be read out from the proper client 
who has the decipher key, and the file content 
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cannot be read out from the server, so that the file 
editing system with a high secrecy tor the file 
content can be realized. 

Also, at the server, the updating with respect to 
the file content of the latest version is made always 5 
at a timing of the completion of the editing by each 
client, so that it becomes possible to realize the 
asynchronous editing by a plurality of clients, with- 
out utilizing the lock mechanism. 

Also, it becomes possible to realize a manner 10 
of usage in which the version which is already old 
in time is edited, and the latest version is made out 
of it. Namely, for the shared file that can be asyn- 
chronously edited, it becomes possible to realize a 
manner of usage in which the editing target is not ts 
necessarily limited to the current version alone. 

Also, in a case of executing the merge pro- 
cessing of the editing results obtained by the asyn- 
chronous editing, it is possible to realize a scheme 
in which only data necessary for the processing at 20 
the client side alone are transmitted from the serv- 
er, and the merged result is returned to the server 
after the necessary processing is executed at the 
client side, so that the wasteful communication of 
portions related to unnecessary records can be 25 
eliminated, and consequently the system efficiency 
can be improved considerably. 

As for the file data structure, by using the 
structure used in the SCCS scheme in which the 
data sequentially inserted from a top of the file are 30 
managed at inserted positions as blocks, and the 
blocks are sequentially divided in a case of the 
partial deletions, rather than the structure used in 
the RCS scheme in which the difference with re- 
spect to the immediately previous (or subsequent) 35 
version is simply left, the determination of the 
insertion/deletion positions required in the merge 
processing can be simplified considerably, so that 
the asynchronous editing becomes easier. 

Also, as the cipher scheme for the data content 40 
in a case of using the data structure of the SCCS 
scheme suitable for the merge processing, the 
stream cipher in bit unit (or byte unit) can be 
utilized. This stream cipher has a property that a 
particular bit (or byte) of the plain text corresponds 45 
to a particular bit (or byte) of the cipher text. For 
this reason, when the enciphered blocks as se- 
quentially divided, it suffices to separate the portion 
after the dividing point and re-encipher that sepa- 
rated portion alone, so that the overhead due to the so 
re-enciphering can be reduced. In addition, it is 
also possible for the server side to confirm that the 
portion before the dividing point has not been 
changed. 

As mentioned above, the shared file editing 55 
system of this second embodiment involves a loop 
of 510 — 502 — 503 in Fig. 5. In the following, the 
second configuration for this second embodiment 



which resolves this loop will be described. 

In this second configuration, the file data struc- 
ture of the modified SCCS scheme shown in Fig. 4 
is used, and the cipher scheme of the 8 bit CFB 
mode among the stream cipher is used. This ci- 
pher scheme has a characteristic that the re-enci- 
phering is totally unnecessary even at a time of 
dividing the blocks as already explained above. 

Fig. 16 shows this second configuration of the 
shared file editing system of this second embodi- 
ment, which generally comprises a plurality of cli- 
ents 211 and a server 210. 

The server 210 further comprises a commu- 
nication (COMM) unit 231 for carrying out a com- 
munication with each client 91 through a commu- 
nication path 111, an editing procedure conversion 
unit 502 for converting the editing procedure, a 
record management unit (for shared file) 510 for 
managing records for shared files, and a data 
memory unit 511 for storing a plurality of files, 
where the editing procedure conversion unit 502, 
the record management unit 510, and the data 
memory unit 511 correspond to the editing proce- 
dure conversion unit 502, the record management 
unit 510. and the the data memory unit 511 in the 
asynchronous editing system of Fig. 5 described 
above. Here, the editing procedure conversion unit 
502 also functions as the record management in- 
formation generation unit 503 of Fig. 5 as well. 

On the other hand, each client 211 further 
comprises a communication (COMM) unit 230 for 
carrying out a communication with the server 210 
through the communication path 111, a memory 

221 for storing files obtained from the server 210, a 
shared file editing unit 222 for editing the shared 
files, and a cipher unit 212 for encipher- 
ing/deciphering the files. 

As shown in Fig. 17, the shared file editing unit 

222 includes the editing unit 500 and the editing 
procedure generation unit 501, which are corre- 
sponding to those in the asynchronous editing sys- 
tem of Fig. 5 described above. 

Now, as a plurality of clients 211 are provided 
in this second embodiment, requests for the follow- 
ing two types of operations occur at various tim- 
ings: 

(a) a reading of file data of a particular version 
(arrow from 510 to 500 in Fig. 5); and 

(b) a writing of editing procedure data obtained 
by converting an editing result (arrow from 501 
to 502 in Fig. 5). 

Here, an exemplary procedure for dealing with 
these requests in this second embodiment will be 
described. 

The client 211 initially requests the data of a 
certain version from the server 210. Then, after the 
data of that version are deciphered and stored in 
the memory 221, the editing is carried out at the 
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editing unit 500, and the editing procedure data are 
generated at the editing procedure generation unit 
501. Here, the editing procedure data includes two 
data types of insertion data and deletion data. The 
insertion data comprises a set of an insertion posi- 
tion (a number of bytes from a top position for 
example) and an insertion block content, while the 
deletion data comprises a set of a deletion start 
position and a deletion end position. 

For the insertion block content, the client 211 
generates the initial value IV and enciphers the 
block by the 8 bit CFB mode. The other data (such 
as the insertion position and the deletion range) are 
not enciphered, and transmitted together with the 
enciphered insertion block content to the server 
210. 

At the server 210 which received this, the in- 
sertion position and the deletion range are con- 
verted (position conversion) into the position data 
with respect to the latest version at that timing by 
the editing procedure conversion unit 502. Then, 
the enciphered insertion block transmitted from the 
client is arranged at the converted insertion posi- 
tion, while the block division and the deletion time 
field entry are made for the converted deletion 
range by the record management unit 510. The 
result obtained so far is then set as the latest 
version. 

In the above procedure, the important point is 
that the conversion of the editing procedure can be 
made in am enciphered state, and for this reason, 
the above described loop for the purpose of the 
editing procedure conversion in the above de- 
scribed general procedure can be resolved. As the 
file data structure and the cipher scheme for en- 
abling the editing procedure conversion in the enci- 
phered state, a combination of the modified SCCS 
scheme and the 8 bit CFB mode is used. The 
similar effect can also be obtained by using the 
other cipher scheme such as the L bit OFB mode 
or the L bit CFB mode for which the re-enciphering 
is unnecessary for the first block in a case of the 
block division, but extra data will be required as the 
editing procedure data to be transmitted from the 
client to the server in such a case, compared with 
a case described above. 

In this manner, in this second embodiment, the 
file content can be read out from the proper client 
who has the decipher key, and the file content 
cannot be read out from the server, so that the file 
editing system with a high secrecy for the file 
content can be realized. 

Also, at the server, the updating with respect to 
the file content of the latest version is made always 
at a timing of the completion of the editing by each 
client, so that it becomes possible to realize the 
asynchronous editing by a plurality of clients, with- 
out utilizing the lock mechanism. 



Thus, in this second embodiment, the arrange- 
ment of the main features in the first configuration 
of Fig. 13 and the second configuration of Fig. 16 
described above can be summarized as shown in 

5 Fig. 18 and Fig. 19, respectively. 

In the configuration of Fig. 18, the block iden- 
tification information may be attached to the record 
management information to be transmitted from the 
client 91 to the server 90 by an operation of the 

io record management information generation unit 
503 on the client 91 side. In such a case, the block 
identification information is not enciphered while 
the entire record management information are enci- 
phered by the cipher unit 1 12, so that the server 90 

75 can manage the new data block indicated by the 
record management information according to the 
attached block identification information which is 
not enciphered and therefore recognizable on the 
server 90 side, even though the data content of the 

20 enciphered record management information is not 
recognizable to the server 90. Alternatively, the 
block identification information may not be attached 
to the record management information to be trans- 
mitted from the client 91 to the server 90, in which 

25 case the appropriate block identification information 
for identifying the new block data indicated by the 
record management information can be attached at 
the record management unit 510 on the server 90 
side. 

30 In the configuration of Fig. 19. only the editing 

procedure data are transmitted from the client 21 1 
to the server 210, and the block identification in- 
formation for identifying the new block data result- 
ing from this editing procedure data is attached by 

35 the operation of the record management informa- 
tion generation unit 503 or the record management 
unit 510 on the server 210 side. Here, only the 
insertion data contents are enciphered by the ci- 
pher unit 212, while the other parts of the editing 

40 procedure data are not enciphered, such that the 
editing procedure conversion unit 502 on the server 
210 side can carry out the conversion of the editing 
procedure data according to these other parts of 
the editing procedure data which are not enci- 

45 phered and therefore recognizable on the server 
210 side, along with the record data provided from 
the record management unit 510. 

It is also possible to modify this configuration 
of Fig. 19 to provide the editing procedure conver- 

so sion unit 502 on the client 21 1 side, between the 
editing procedure generation unit 501 and the ci- 
pher unit 212, to realize a hybrid of the configura- 
tions of Figs. 18 and 19. In such a case, only the 
converted editing procedure data are transmitted 

55 from the client 211 to the server 210, and the block 
identification information for identifying the new 
block data resulting from this converted editing 
procedure data is attached by the operation of the 
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record management information generation unit 
503 or the record management unit 510 on the 
server 210 side. In this case, only the converted 
insertion data contents are enciphered by the ci- 
pher unit 212, while the other parts of the editing 
procedure data are not enciphered, such that the 
record management information generation unit 
5023 on the server 210 side can carry out the 
generation of the record management information 
according to these other parts of the converted 
editing procedure data which are not enciphered 
and therefore recognizable on the server 210 side. 

Now, the above described first feature concern- 
ing the file content secrecy with respect to the 
server and the above described second feature 
concerning the asynchronous editing are separately 
realizable. In the following, the embodiments of a 
shared file editing system implementing one of 
these features separately will be described in de- 
tail. 

First, the third embodiment of a shared file 
editing system according to the present invention, 
in which the above described second feature con- 
cerning the asynchronous editing is implemented 
on the client server type system will be described 
in detail. 

In this third embodiment, the individual features 
related to the file structure, the record management 
scheme, and the asynchronous editing system are 
basically the same as those for the first embodi- 
ment described above, and their detailed descrip- 
tions will not be repeated here. In the following, the 
configuration and the operation characteristic to 
this third embodiment will be described. 

Fig. 20 shows a configuration of the shared file 
editing system of this third embodiment, which 
generally comprises a plurality of clients 701 and a 
server 710. 

The server 710 further comprises a commu- 
nication (COMM) unit 731 for carrying out a com- 
munication with each client 701 through a commu- 
nication path 1 1 1 , a merge processing unit 740 for 
carrying out the merge processing, and a data 
memory unit 511 for storing a plurality of files, 
where the data memory unit 511 corresponds to 
the the data memory unit 511 in the asynchronous 
editing system of Fig. 5 described above. 

On the other hand, each client 701 further 
comprises a communication (COMM) unit 730 for 
carrying out a communication with the server 710 
through the communication path 111, a memory 

721 for storing files obtained from the server 710, 
and a shared file editing unit 722 for editing the 
shared files. 

As shown in Fig. 21, the shared file editing unit 

722 of the client 701 includes the editing unit 500 
and the editing procedure generation unit 501, 
which are corresponding to those in the asyn- 



chronous editing system of Fig. 5 described above. 

As shown in Fig. 22, the merge processing unit 
740 of the server 710 includes the editing proce- 
dure conversion unit 502, the record management 
5 information generation unit 503, and the record 
management unit 510, which are corresponding to 
those in the asynchronous editing system of Fig. 5 
described above. 

Now, as a plurality of clients 701 are provided 
w in this third embodiment, requests for the following 
two types of operations occur at various timings: 

(a) a reading of file data of a particular version 
(arrow from 510 to 500 in Fig. 5); and 

(b) a writing of editing procedure data obtained 
15 by converting an editing result (arrow from 501 

to 502 in Fig. 5). 
Here, an exemplary procedure for dealing with 
these requests in this second embodiment will be 
described. 

20 In this case, the client 701 requests the file 

data of a particular version from the server 710, 
and after that file is stored in the memory 721. the 
editing is carried out at the editing unit 500, the 
editing procedure data are generated at the editing 

25 procedure generation unit 501, and the obtained 
editing procedure data are transmitted to the server 
710. 

At the server 710, the editing procedure data 
are entered into the queue one by one, and the 

30 merge processing unit 740 sequentially takes out 
the editing procedure data in the queue, converts 
them into the records and store them. Unlike a 
case of the system with cipher function described 
above, this third embodiment is characterized in 

35 that the server 710 by itself can carry out the 
editing procedure conversion with respect to the 
latest version. Namely, the client 701 carries out 
the editing procedure conversion according to the 
editing procedure data and the record data, and 

40 then store the result as the record. Consequently, 
the above mentioned loop of 510 — 502 — 503 in 
Fig. 5 is absent in this third embodiment, and 
therefore there is no need for the lock mechanism 
for the purpose of preventing the repetitive pro- 

45 cessing through the loop. In addition, the function 
of the shared file editing unit 722 provided on the 
client 701 side can also be reduced. 

Here, just as in a case of the embodiment 
incorporating the first feature concerning the file 

so content secrecy with respect to the server, it is also 
possible to use a configuration in which the editing 
procedure conversion unit 502 and the record man- 
agement information generation unit 503 are pro- 
vided on the client 701 side. In such a case, the 

55 operation of each element is substantially similar 
as described above for the second embodiment. It 
is also possible to move the editing procedure 
generation unit 501 from the shared file editing unit 
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722 provided on the client 701 to the server 710 
side. 

Thus, in this third embodiment, at the server, 
the updating with respect to the file content of the 
latest version is made always at a timing of the 
completion of the editing by each client, so that it 
becomes possible to realize the asynchronous ed- 
iting by a plurality of clients, without utilizing the 
lock mechanism. 

Also, it becomes possible to realize a manner 
of usage in which the version which is already old 
in time is edited, and the latest version is made out 
of it. Namely, for the shared file that can be asyn- 
chronously edited, it becomes possible to realize a 
manner of usage in which the editing target is not 
necessarily limited to the current version alone. 

Also, in a case of executing the merge pro- 
cessing of the editing results obtained by the asyn- 
chronous editing, it is possible to realize a scheme 
in which only data necessary for the merging at the 
client side alone are transmitted from the server, 
and the merged result is returned to the server 
after the necessary processing is executed at the 
client side, so that the wasteful communication of 
portions related to unnecessary records can be 
eliminated, and consequently the system efficiency 
can be improved considerably. 

As for the file data structure, by using the 
structure used in the SCCS scheme in which the 
data sequentially inserted from a top of the file are 
managed at inserted positions as blocks, and the 
blocks are sequentially divided in a case of the 
partial deletions, rather than the structure used in 
the RCS scheme in which the difference with re- 
spect to the immediately previous (or subsequent) 
version is simply left, the determination of the 
insertion/deletion positions required in the merge 
processing can be simplified considerably, so that 
the asynchronous editing becomes easier. 

Next, the fourth embodiment of a file editing 
system according to the present invention, in which 
the above described first feature concerning the file 
content secrecy with respect to the server is imple- 
mented on the client server type system will be 
described in detail. 

The file handled in this fourth embodiment 
includes a plurality of block data and block iden- 
tification information, and each block data are enci- 
phered in units of block data. The file data has the 
data structure such as that of Fig. 2, Fig. 3, or Fig. 
4 described above, for example, but besides these, 
this fourth embodiment is also applicable to various 
other systems and schemes, such as a scheme for 
enciphering the program in units of sub-routines, 
and a scheme for dealing with a plurality of data 
files which are linked together as in the hypertext, 
in which the data files are enciphered in units of 
data files and linked portions are not enciphered. In 



this manner, it becomes possible to realize an 
efficient manner of utilization in which the client 
can read out only the necessary portion while 
maintaining the secrecy of the module content with 

5 respect to the server. 

Also, in this fourth embodiment, with respect to 
the files with the data structure as described above, 
the cipher scheme described above for the first 
embodiment is used. 

10 Fig. 23 shows a configuration of the file editing 

system of this fourth embodiment, which generally 
comprises a plurality of clients 801 and a server 
810. 

The server 810 further comprises a commu- 
75 nication (COMM) unit 831 for carrying out a com- 
munication with each client 801 through a commu- 
nication path 1 1 1 , a data management unit 840 for 
managing the file data, and a data memory unit 
511 for storing a plurality of files. 
20 On the other hand, each client 801 further 

comprises a communication (COMM) unit 830 for 
carrying out a communication with the server 810 
through the communication path 111, a memory 
821 for storing files obtained from the server 810, a 
25 file editing unit 822 for editing the files, and a 
cipher unit 812 for enciphering/deciphering the 
files. 

As shown In Fig. 24, the cipher unit 812 in- 
cludes a communication (COMM) unit 832 con- 

30 nected with the file editing unit 822, an enci- 
pher/decipher processing unit 8121 connected with 
the communication unit 832, and a key memory 
unit 8122 connected with the encipher/decipher 
processing unit 8121. 

35 In this configuration, the client 801 requests the 

file data of a particular version from the server 810, 
and after that file is stored in the memory 821, the 
editing is carried out at the file editing unit 822. At 
this point, the file is enciphered in units of block 

40 data as already mentioned above, so that the file is 
deciphered by using the decipher key registered in 
the key memory unit 8122 at the encipher/decipher 
processing unit 8121, After the editing of the file is 
finished, the file is enciphered by using the cipher 

45 key registered in the key memory unit 8122 at the 
encipher/decipher processing unit 8121, and trans- 
mitted to the server 810, such that the file in the 
data memory unit 511 is updated by the data 
management unit 840 at the server 810. 

so In this manner, in this fourth embodiment, it is 

possible to realize the file editing system with a 
high secrecy for the file content in which the file 
content cannot be read out from the server. 

Also, the client can obtain only the necessary 

55 data block among the files through the communica- 
tion, so that it is possible to reduce the amount of 
communication, and also it suffices to deci- 
pher/encipher the necessary blocks alone, so that it 
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is possible to reduce the amount of processing at 
the client side, and consequently the buffer (mem- 
ory) required for the client can also be reduced. 

Now, in this fourth embodiment, it is also pos- 
sible to apply the record management scheme as 
described above for the first embodiment, as fol- 
lows. 

In this case, the file data structure of Fig. 2, 
Fig. 3, or Fig. 4 described above is used. Also, with 
respect to the files with such a data structure, the 
cipher scheme described above for the first em- 
bodiment is used. 

Here, the asynchronous editing is not carried 
out, so that it is possible to use the record man- 
agement system in which the editing procedure 
conversion unit 502 in the asynchronous editing 
system of Fig. 5 is omitted and the editing proce- 
dure generation unit 501 and the record manage- 
ment information generation unit 503 can be con- 
nected directly, and the record management unit 
510 is set as the data management unit 840 which 
is modified to have a function to manage the data 
memory unit 511 alone. This record management 
system is distributedly arranged in the file editing 
unit 822 and the data management unit 840. 

Here, as long as the editing unit 500 is imple- 
mented on the file editing unit 822 of the client 
801, and the data management unit 840 and the 
data memory unit 511 are implemented on the 
server 810, the other elements may be distributed- 
ly arranged in any desired form. 

Here, as a preferable form, the data manage- 
ment unit 840 and the data memory unit 511 alone 
are implemented on the server 810 while all the 
other elements are implemented on the client 801 , 
as in Fig. 23, will be described. 

In this configuration, the client 801 requests the 
file data of a particular version from the server 810, 
and after that file is stored in the memory 821, the 
editing is carried out at the file editing unit 500. At 
this point, the file is enciphered in units of block 
data as already mentioned above, so that the file is 
deciphered by using the decipher key registered in 
the key memory unit 81 22 at the encipher/decipher 
processing unit 8121, After the editing of the file is 
finished, the editing procedure data are generated 
at the editing procedure generation unit 501. Then, 
the obtained editing procedure data are converted 
into the record data in a format suitable for the 
record management scheme used at the record 
management information generation unit 503. Then, 
the record data are enciphered by using the cipher 
key registered in the key memory unit 8122 at the 
encipher/decipher processing unit 8121, and trans- 
mitted to the server 810, such that the file in the 
data memory unit 511 is updated by the data 
management unit 840 at the server 810. 



In this manner, the file version management 
and the file data secrecy with respect to the file 
management server can be realized simultaneous- 
ly. 

5 Also, in a case the file data structure of the 

difference pile up scheme shown in Fig. 2 is used, 
the completeness of the record can be guaranteed 
by the file management server side alone. 

Also, in a case the file data structure of the 

10 RCS scheme shown in Fig. 3 is used, the reading 
of the file in the current version and the deletion of 
old records can be made easier in the file version 
management. 

Also, in a case the file data structure of the 

75 modified SCCS scheme shown in Fig. 4 is used, 
the deletion of old records in the file version man- 
agement can be made easier. 

Also, in a case of using the stream cipher as 
the cipher scheme, in the enciphering at a time of 

20 block division, a portion from a top of the block to 
the division point can be re-utilized in the enci- 
phered state, and it suffices to re-encipher only a 
portion after the division point. It is also possible to 
use the cipher scheme in which absolutely no re- 

25 enciphering is necessary. This cipher scheme is 
advantageous in a case of sequentially dividing 
blocks as in the SCCS scheme. 

Next, the fifth embodiment of a shared file 
editing system according to the present invention 

30 will be described in detail. In this fifth embodiment, 
the shared file editing system of Fig. 13, Fig. 16, or 
Fig. 20 described above is further equipped with an 
additional function for delaying an execution of a 
deletion of a version in response to a deletion 

35 request for a certain version of a certain file, until 
no client remains to be editing that certain version 
of that certain file. 

In the system employing the record manage- 
ment, it is possible to provide a function for delet- 

40 ing some versions among the records. Such a 
deletion of a version may be made when the client 
executes a deletion command for example, or in a 
case the system automatically deletes any version 
for which more than a prescribed period of time 

45 has elapsed since its creation. 

In the shared file editing system with the asyn- 
chronous editing function according to the present 
invention, at a time of deleting a version, there 
should not be any client who is editing that deletion 

50 target version. This is because the file manage- 
ment server carries out the merge processing for 
converting the version accessed by the client into 
the latest version in the file management server in 
such a system, and if a version is deleted while 

55 that version is edited by some client in such a 
system, the merge processing for the editing made 
by that client would become impossible. 
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In this fifth embodiment, in order to realize the 
version deletion function, the file management 
server is provided with means for counting a num- 
ber of clients who are editing each version of each 
file, in correspondence to each version of each file 
managed by the file management server. By this 
means, the file management server can judge 
whether there exists any client who is editing each 
version of each file. Namely, when the count value 
for a specified version of a specified file is 0, it 
implies that there is no client who is editing that 
version of that file, whereas when that count value 
is not equal to 0, it implies that there exists a client 
who is editing that version of that file. 

Then, the file management server of this fifth 
embodiment is further provided with means for 
delaying the execution of the deletion of a version 
when the deletion of a certain version of a certain 
file is requested and the count value for that ver- 
sion of that file is not equal to 0, until that count 
value becomes 0. By this means, the file manage- 
ment server is not going to delete that version of 
that file while there exists a client who is editing 
that version of that file which is the deletion target, 
so that the merge processing for the editing made 
by that client can be carried out without a trouble. 

Fig. 25 shows a configuration of the shared file 
editing system of this fifth embodiment as outlined 
above, which is based on the shared file editing 
system of Fig. 13 described above. 

In this configuration of Fig. 25, each access 
requesting client 91 and the communication path 
111 are substantially similar as those in Fig. 13. 
The file management server 95 differs from that of 
Fig. 13 in that it further includes a client counting 
unit 900. 

As shown in Fig. 26, this client counting unit 
900 comprises a branching unit 901, an editing 
start processing unit 902, a deletion request pro- 
cessing unit 903, and an editing end processing 
unit 904, a count memory unit 905, and a deletion 
command issuing unit 906. 

The basic functions of this client counting unit 
900 include the counting how many clients are 
editing each version of each file in correspondence 
to each version of each file managed by the file 
management server 95, and the delaying of the 
execution of a deletion of a version when the 
deletion of a certain version of a certain file is 
requested from a certain client but the count value 
for that version of that file counted by the client 
counting means 900 is not equal to 0, until that 
count value becomes 0. 

Here, the basic role of the count memory unit 
905 in the client counting unit 900 is that, for each 
version of each file, it stores the count value (an 
integer) and a deletion delay flag (1 bit indicating 
truth or false) in correspondence. The count value 



is a counter for counting how many clients are 
editing that version of that file, while the deletion 
delay flag is a flag for indicating that the execution 
of the deletion is delayed because the count value 
5 is not equal to 0. 

An exemplary data structure of the data stored 
in the count memory unit 905 is shown in Fig. 27, 
which is in a form of array in two steps. The array 
of the first step makes a correspondence between 

io the file ID and the arrays of the second step, which 
is an array of entries with each entry containing a 
pair of the file ID and a count array address. Each 
array of the second step stores the count value and 
the deletion delay flag for different versions of each 

is file, which is an array of entries with each entry 
containing a pair of the count value and the dele- 
tion delay flag. In this array of the second step, the 
version number is referred as an index in the array. 
Thus, for example, C11, C12, and C13 shown in 

20 Fig. 27 are the count values for the versions with 
version numbers 1 , 2, and 3 of the file with the file 
ID1, while F11, F12, and F13 shown in Fig. 27 are 
the deletion delay flags for the versions with ver- 
sion numbers 1. 2, and 3 of the file with the file 

25 ID1. Here, the initial value of each count value is 
set to be 0, and the initial value of each deletion 
delay flag is set to be false (or a value indicating 
false such as "0"). 

In this fifth embodiment, the client 91 makes 

30 the editing start declaration to the file management 
server 95 immediately before starting the editing of 
the file. This editing start declaration is made by 
transmitting a command word indicating that it is 
the editing start declaration, followed by the file ID 

35 of the file to be a target of the editing and the 
version number of the version to be edited, from 
the client 91 to the file management server 95, 
through the communication path 111. 

The communication data received by the file 

40 management server 95 are then entered into the 
branching unit 901. At the branching unit 901, the 
first one word of the communication data is read 
out, and when it is judged that it is the command 
word indicating that it is the editing start declara- 

45 tion, the following file ID and the version number in 
the communication data are entered into the editing 
start processing unit 902. 

At the editing start processing unit 902, when 
the input from the branching unit 901 is received, 

so an access to the count memory unit 905 is made 
to increase the count value corresponding to the 
specified version of the specified file ID by one. 

On the other hand, the communication data 
received at the branching unit 901 are also given to 

55 the record management unit 510 either as they are 
or as the file ID and the version number are pro- 
cessed appropriately. Then, after the editing start 
declaration is processed as described above, the 
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editing of the file by the client 91 is carried out, At 
this point, the file editing mechanism is similar to 
that in the configuration of Fig. 13 described above. 

Next, a processing mechanism for a case of 
deleting a version of a file will be described, In this 
fifth embodiment, the version deletion request is 
also made by transmitting a command word in- 
dicating that it is the version deletion request, fol- 
lowed by the file ID of the file to be a target of the 
deletion and the version number of the version to 
be deleted, from the client 91 to the file manage- 
ment server 95, through the communication path 
111. 

The communication data received by the file 
management server 95 are then entered into the 
branching unit 901. At the branching unit 901, the 
first one word of the communication data is read 
out, and when it is judged that it is the command 
word indicating that it is the version deletion re- 
quest, the following file ID and the version number 
in the communication data are entered into the 
deletion request processing unit 903. 

At the deletion request processing unit 903, 
when the input from the branching unit 901 is 
received, the processing according to the flow 
chart of Fig. 28 is carried out as follows. 

At the deletion request processing unit 903, the 
count memory unit 905 is accessed first, and the 
count value C for the specified version number of 
the specified file ID is obtained (step S21). 

Next, whether that count value C is equal to 0 
or not is judged (step S22). When that count value 
C is equal to 0, the command for deleting the 
specified version of the specified file is issued from 
the deletion command issuing unit 906 to the 
record management unit 510 (step S23), whereas 
when that count value C is not equal to 0, the count 
memory unit 905 is accessed and the deletion 
delay flag for the specified version number of the 
specified file ID is set to be true (or a value 
indicating true such as "1")(step S24). 

Next, the processing at an end of the editing 
will be described. In this fifth embodiment, the 
client 91 makes the editing end declaration to the 
file management server 95 immediately after end- 
ing the editing of the file. This editing end declara- 
tion is made by transmitting a command word 
indicating that it is the editing end declaration, 
followed by the file ID of the file for which the 
editing is finished and the version number of the 
version for which the editing is finished, from the 
client 91 to the file management server 95, through 
the communication path 111. 

The communication data received by the file 
management server 95 are then entered into the 
branching unit 901. At the branching unit 901, the 
first one word of the communication data is read 
out, and when it is judged that it is the command 



word indicating that it is the editing end declaration, 
the following file ID and the version number in the 
communication data are entered into the editing 
end processing unit 904. Here, whenever neces- 
5 sary, the communication data received at the 
branching unit 901 are also given to the record 
management unit 510 either as they are or as the 
file ID and the version number are processed ap- 
propriately. 

70 At the aditing end processing unit 904, when 

the input from the branching unit 901 is received, 
the processing according to the flow chart of Fig. 
29 is carried out as follows. 

At the editing end processing unit 904, the 

75 count memory unit 905 is accessed first, and the 
count value C and the deletion delay flag F for the 
specified version number of the specified file ID is 
obtained (step S31). Then, that count value C is 
reduced by one (step S32), and the resulting count 

20 value C is stored into count memory unit 905 (step 
S33). 

Next, whether that count value is equal to 0 or 
not is judged (step S34). When that count value C 
is not equal to 0, the processing at the editing end 

25 processing unit 904 is finished. On the other hand, 
when that count value C is equal to 0, whether that 
deletion delay flag F is true or false is judged (step 
S35). When that deletion delay flag F is false, the 
processing at the editing end processing unit 904 

30 is finished. On the other hand, when that deletion 
delay flag F is true, the command for deleting the 
specified version of the specified file is issued from 
the deletion command issuing unit 906 to the 
record management unit 510 (step S36). 

35 It is to be noted that, at the branching unit 901 , 

when the first one word of the communication data 
is read out, and when it is judged as none of the 
command words for the editing start declaration, 
the version deletion request, and the editing end 

40 declaration described above, the communication 
data are entered into the record management unit 
510 as they are. 

Next, an exemplary deletion command execu- 
tion processing at the record management unit 510 

45 will be described. Here, the deletion command 
processing procedure differs depending on which 
one of the difference pile up scheme, the RCS 
scheme, and the modified SCCS scheme is used 
by the record management unit 510, so that an 

50 example for each of these three cases will be 
described one by one. 

In the following explanation, the following sym- 
bols will be used. 

r : a version number of the deletion target 

55 version 

f : a version number of the oldest version 
stored by the record management unit 510 among 
the records for the target file (In many case, f = 1, 

23 



', JSDOCID: <EP 0674253A1J_> 

L 



45 



EP 0 674 253 A1 



46 



but when the version 1 had been deleted by the 
version deletion command in the past, f may take a 
value other than 1 ) 

n : a version number of the latest version 
(current version) stored by the record management 
unit 51 0 among the records for the target file 

p(x) : a version number of a version imme- 
diately previous to a certain version x among the 
versions stored by the record management unit 
510 (In many case, p = x-1, but if the version x-1 
had been deleted in the past, p = x-2, and if the 
version x-2 had also been deleted in the past, p = 
x-3, and so on) 

s(x) : a version number of a version imme- 
diately subsequent to a certain version x among 
the versions stored by the record management unit 
510 (In many case, s = x + 1, but if the version 
x + 1 had been deleted in the past, s = x + 2, and if 
the version x + 2 had also been deleted in the past, 
s = x + 3, and so on) 

V[x] : (content of) version x V[x] - V[y] : a 
difference between version x and version y 

First, a case in which the record management 
unit 510 is carrying out the record management 
according to the difference pile up scheme will be 
explained. Fig. 30 shows a flow chart for the dele- 
tion command execution processing in this case. 

(i) A case in which the deletion target is not the 
first version of the records or the current version 
(a case of r * f at the step S41 and r * n at the 
step S45) 

In this case, the previous version (V[P(01) 
and the subsequent version (V[s(r)]) of the dele- 
tion target version are restored (step S47), a 
difference (V[s(r)] - V[p(r)]) between these two 
versions is obtained (step S48), and the differ- 
ences (V[s(r)] - V[r]) and (V[r] - V[p(r)]) of the 
deletion target version with respect to its pre- 
vious and subsequent versions are replaced by 
the obtained difference (V[s(r)] - V[p(r)]) (step 
S49). 

(ii) A case in which the deletion target is the first 
version of the records (a case of r = f at the 
step S41) 

In this case, the subsequent version (V[s(r)]) 
of the deletion target version is restored (step 

542) , the first version (V[r]) of the records and a 
difference between the first version and its sub- 
sequent version (V[s(r)] - V[r]) are deleted (step 

543) , and Vfs(r)] is set to be a new first version 
of the records (step S44). 

(iii) A case in which the deletion target is the last 
version (current version) of the records (a case 
of r = n at the step S45) 

In this case, a difference (V[r] - V[p(r)J) 
between that version and its previous version is 
deleted (step S46). 



Next, a case in which the record management 
unit 510 is carrying out the record management 
according to the RCS scheme will be explained. 
Fig. 31 shows a flow chart for the deletion com- 
5 mand execution processing in this case. 

(i) A case in which the deletion target is not the 
first version of the records or the current version 
(a case of r * f at the step S61 and r * n at the 
step S65) 

io In this case, the previous version (V[p(r)]) 

and the subsequent version (V[s(r)]) of the dele- 
tion target version are restored (step S67), a 
difference (V[p(r)] - V[s(r)]) between these two 
versions is obtained (step S68), and the differ- 

is ences (V[p(r)] - V[r]) and (V[r] - V[s(r)]) of the 
deletion target version with respect to its pre- 
vious and subsequent versions are replaced by 
the obtained difference (V[p(0l - V[s(r)]) (step 
S69). 

20 (ii) A case in which the deletion target is the first 
version of the records (a case of r = f at the 
step S61) 

In this case, a difference (V[r] - V[s(r)]) 
between that version and its previous version is 
25 deleted (step S62). 

(iii) A case in which the deletion target is the last 
version (current version) of the records (a case 
of r = n at the step S63) 

In this case, the previous version (V[p(r)]) of 
30 the current version is restored (step S64), a 
difference between the current version and its 
previous version (V[p(01 - VM) is deleted (step 
S65), and V[p(r)] is set to be a new current 
version (step S66). 
35 Next, a case in which the record management 

unit 510 is carrying out the record management 
according to the modified SCCS scheme will be 
explained. Fig. 32 shows a flow chart for the dele- 
tion command execution processing in this case. 
40 Here, the flow chart of Fig. 32 shows the deletion 
processing procedure for one block constituting the 
record. The deletion processing at the record man- 
agement unit 510 is carried out by applying this 
procedure to all the blocks which contain the dele- 
45 tion target version. 

In the following explanation, the following sym- 
bols will also be used. 

i : a creation time of a block which is a pro- 
cessing target 

so d : a deletion time of a block which is a 

processing target 

Here, the block which is not yet deleted even 
in the current version will be designated by d = «. 
(i) A case in which the deletion target is not the 
55 current version (a case of r * n at the step S81) 
In this case, for those blocks which existed 
only in the deletion target version (i = r at the 
step S85 and d = s(r) at the step S86), these 
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blocks are deleted from the record data (step 
S90). 

For those blocks which are created in the 
deletion target version (i = r at the step S85 
and d * s(r) at the step S86), these blocks are 
regarded as created in the subsequent version 
(V[s(r)]) of the deletion target version (step S87). 

For those blocks which are deleted in the 
deletion target version (i * r at the step S85 and 
d = r at the step S88), these blocks are re- 
garded as deleted in the subsequent version (V- 
[s(r)]) of the deletion target version (step S89). 
(ii) A case in which the deletion target is the 
current version (a case of r = n at the step 
S81) 

In this case, for those blocks which are 
created in the current version (i = n at the step 
S82), these blocks are deleted from the record 
data (step S90). 

For those blocks which are deleted in the 
current version (i * n at the step S82 and d = n 
at the step S83), these blocks are regarded as 
the blocks which have not been deleted (d = «>) 
(step S84). 

Here, after the above processing is applied to 
all the blocks, for arbitrary neighboring two blocks 
in the records, if they have the identical creation 
time and the identical deletion time, these two 
blocks may be united together. 

It is to be noted that, in the above, a case of 
deleting one version by one deletion command has 
been explained, but even in the general version 
management system, by processing the deletion 
request for a plurality of versions by decomposing 
it into a plurality of deletion commands for each 
one of the target versions, it is easy to obtain the 
similar effect as providing a function to delete a 
plurality of versions by one deletion command, 

As described, according to this fifth embodi- 
ment, a number of clients who are editing each 
version of each file is stored for each version of 
each file, and the execution of the deletion is 
delayed until no client remains to be editing the 
deletion target version of the target file, even when 
there is a request for deleting that version of that 
file from the user, so that no client can delete the 
version during the editing, and therefore it is possi- 
ble to realize the asynchronous editing system in 
which the merge processing can be executed with- 
out a trouble. 

Here, the deletion of the record in this fifth 
embodiment has been made as the deletion re- 
quest is issued from the client to the file manage- 
ment server, but it is also possible to consider a 
configuration in which the deletion request is gen- 
erated from element other than the client. For ex- 
ample, for any record for which a prescribed period 
of time has elapsed since its creation, the deletion 



request can be generated automatically within the 
server, Also, in a case it is sufficient to support the 
asynchronous editing for the latest version alone, 
and no editing for the past versions is included, it 

5 suffices to use a configuration in which the deletion 
request for a previous version is generated auto- 
matically within the server at a timing of a creation 
of a new version. 

It is to be noted that this fifth embodiment has 

io been a case in which the client counting unit is 
added to a configuration of Fig. 13 in which the file 
content secrecy function and the asynchronous ed- 
iting function are implemented on the client server 
type system, but it is also possible to add the 

75 client counting unit to a configuration of Fig. 16 or 
Fig. 20 in which the asynchronous editing function 
is implemented on the client server type system. In 
such a case, a configuration and a function of the 
client counting unit can be substantially the same 

20 as described above for a case of using a configura- 
tion of Fig. 13. 

Next, the sixth embodiment of a shared file 
editing system according to the present invention 
will be described in detail. In this sixth embodi- 

25 ment, the shared file editing system of Fig. 13, Fig. 
16, or Fig. 20 described above is further equipped, 
when the block data of a certain file are enci- 
phered, with a function for delaying an execution of 
a deletion of a version in response to a deletion 

30 request for a certain version of a certain file, until 
no client remains to be editing that certain version 
of that certain file as in Fig. 25 described above, 
and an additional function for reconstructing the 
block data of that certain file. 

35 As mentioned above, in the system employing 

the record management, it is possible to provide a 
function for deleting some versions among the 
records. This sixth embodiment provides a function 
for deleting the record of a certain version when 

40 the block data are enciphered. In addition, this sixth 
embodiment also provides a function for reducing a 
number of blocks by reconstructing the block data. 

In order to realize such additional functions, in 
this sixth embodiment, the client is provided with 

45 means for reconstructing the block data of the file. 
By this means, the client can delete the record of a 
certain version and reconstruct the file data into the 
desired blocks. 

Fig. 33 shows a configuration of the shared file 

so editing system of this sixth embodiment as outlined 
above, which is based on the shared file editing 
system of Fig. 25 described above. 

In this configuration of Fig. 33, the file manage- 
ment server 95 and the communication path 1 1 1 

55 are substantially similar as those in Fig. 25. Each 
access requesting client 92 differs from that of Fig. 
25 in that it further includes a block data recon- 
struction unit 910. Here, this block data reconstruc- 
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tion unit 910 may not necessarily be provided in 
every one of the clients 92 of the system. Thus, in 
this sixth embodiment, the version deletion request 
for a certain file is executed when the count value 
of the client counting unit 900 is equal to 0, just as 5 
in the fifth embodiment described above. 

Now, an exemplary execution processing for 
deleting the record of a certain version in a case 
the block data are enciphered will be explained. 
Here, the version deletion processing procedure 10 
differs depending on which one of the difference 
pile up scheme, the RCS scheme, and the modi- 
fied SCCS scheme is used by the record manage- 
ment unit 510, so that an example for each of 
these three cases will be described one by one. 75 

In the following explanation, the following sym- 
bols will be used. 

r : a version number of the deletion target 
version 

f : a version number of the oldest version 20 
stored by the record management unit 510 among 
the records for the target file (In many case, f = 1, 
but when the version 1 had been deleted by the 
version deletion command in the past, f may take a 
value other than 1 ) 25 

n : a version number of the latest version 
(current version) stored by the record management 
unit 510 among the records for the target file 

p(x) : a version number of a version imme- 
diately previous to a certain version x among the 30 
versions stored by the record management unit 
510 (In many case, p = x-1 f but if the version x-1 
had been deleted in the past, p = x-2, and if the 
version x-2 had also been deleted in the past, p = 
x-3, and so on) 35 

s(x) : a version number of a version imme- 
diately subsequent to a certain version x among 
the versions stored by the record management unit 
510 (In many case, s = x + 1, but if the version 
x + 1 had been deleted in the past, s = x + 2, and if 40 
the version x + 2 had also been deleted in the past, 
s = x + 3, and so on) 

V[x] : (content of) version x 

V[x] - V[y] : a difference between version x and 
version y 45 

First, a case in which the record management 
unit 510 is carrying out the record management 
according to the difference pile up scheme will be 
explained. Fig. 34 shows a flow chart for the pro- 
cessing procedure at the block data reconstruction 50 
unit 910 in the client 92 in this case, while Fig. 35 
shows a flow chart for the processing procedure at 
the record management unit 510 in the server 95 
which received the deletion request from the client 
92 in this case. 55 

First, the processing procedure of the client 92 
will be described with reference to Fig. 34. 



(i) A case in which the deletion target is not the 
first version of the records or the current version 
(a case of r * f at the step S101 and r * n at the 
step S106) 

In this case, the subsequent version (V[s(r)]) 
of the deletion target version is read out from 
the server 95 (step S108). Here, (a plurality of) 
enciphered block data are transmitted from the 
server 95. 

Then, ihe transmitted block data are de- 
ciphered by the cipher unit 112, and the subse- 
quent version (V[s(r)]) and the previous version 
(V[p(r)]) of the deletion target version are re- 
stored (step S109). Here, V[p(r)] can be ob- 
tained from V[s(r)] read out at the step SI 08. 

Then, a difference (V[s(r)] - V[p(r)]) between 
these two versions is obtained (step S1 10). 

Then, the obtained difference (V[s(r)] - V[p- 
(r)]) is enciphered by the cipher unit 112 as a 
new block data (step S1 1 1). 

Finally, this enciphered block data and the 
deletion request for the version r are transmitted 
to the server 95 (step S1 12). 

(ii) A case in which the deletion target is the first 
version of the records (a case of r = f at the 
step S101) 

In this case, the subsequent version (V[s(r)]) 
of the deletion target version is read out from 
the server 95 (step S102). Here, (a plurality of) 
enciphered block data are transmitted from the 
server 95. 

Then, the transmitted block data are de- 
ciphered by the cipher unit 112, and the subse- 
quent version (V[s(r)]) of the deletion target ver- 
sion is restored (step S103). 

Then, the obtained (V[s(r)]) is enciphered by 
the cipher unit 112 as a new block data (step 
S104). 

Finally, this enciphered block data and the 
deletion request for the version r are transmitted 
to the server 95 (step S105). 

(iii) A case in which the deletion target is the last 
version (current version) of the records (a case 
of r a n at the step S106) 

In this case, the deletion request for the 
version r is transmitted to the server 95 (step 
S107). 

Next, the processing procedure of the server 
95 which received the deletion request from the 
client 92 will be described with reference to Fig. 
35. 

(i) A case in which the deletion target is not the 
first version of the records or the current version 
(a case of r * f at the step S121 and r * n at the 
step S123) 

In this case, a block data (V[s(r)] - V[r]) and 
a block data (V[r] - V[p(r)]) are deleted, and a 
block data (V[s(r)] - V[p(r)]) transmitted from the 
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client 92 is inserted instead (step S125). 

(ii) A case in which the deletion target is the first 
version of the records (a case of r = f at the 
step S101) 

In this case, a block data V[r] and a block 5 
data (V[s(r)] - V[r]) are deleted, and a block data 
(V[s(r)] transmitted from the client 92 is inserted 
instead (step S1 22). 

(iii) A case in which the deletion target is the last 
version (current version) of the records (a case io 
of r = n at the step S106) 

In this case, a block data (V[r] - V[p(r)]) is 
deleted (step S124). 

By the above procedure, the record of the 
version r can be deleted. 75 

Next, a case in which the record management 
unit 510 is carrying out the record management 
according to the RCS scheme will be explained. 
Fig. 36 shows a flow chart for the processing 
procedure at the block data reconstruction unit 910 20 
in the client 92 in this case, while Fig. 37 shows a 
flow chart for the processing procedure at the 
record management unit 510 in the server 95 which 
received the deletion request from the client 92 in 
this case. 25 

First, the processing procedure of the client 92 
will be described with reference to Fig. 36. 

(i) A case in which the deletion target is not the 
first version of the records or the current version 

(a case of r * f at the step S131 and r * n at the 30 
step S133) 

In this case, the previous version (V[p(r)]) of 
the deletion target version is read out from the 
server 95 (step S138). Here, (a plurality of) 
enciphered block data containing the latest ver- 35 
sion are transmitted from the server 95. 

Then, the transmitted block data are de- 
ciphered by the cipher unit 112, and the subse- 
quent version (V[s(r)]) and the previous version 
Mp(r)]) of the deletion target version are re- 40 
stored (step S139). Here, V(s(r)] can be obtained 
from V[p(r)] read out at the step S138. 

Then, a difference (V[p(r)] - V[s(r)]) between 
these two versions is obtained (step S140). 

Then, the obtained difference (V[p(r)] - V[s- 45 
(r)]) is enciphered by the cipher unit 112 as a 
new block data (step S141). 

Finally, this enciphered block data and the 
deletion request for the version r are transmitted 
to the server 95 (step S142). 50 

(ii) A case in which the deletion target is the first 
version of the records (a case of r = f at the 
step S131) 

In this case, the deletion request for the 
version r is transmitted to the server 95 (step 55 
S132). 

(iii) A case in which the deletion target is the last 
version (current version) of the records (a case 



of r = n at the step S133) 

In this case, the previous version (V[p(r)]) of 
the deletion target version is read out from the 
server 95 (step S134). Here, (a plurality of) 
enciphered block data containing the latest ver- 
sion are transmitted from the server 95. 

Then, the transmitted block data are de- 
ciphered by the cipher unit 112, and the pre- 
vious version (V[p(r)]) of the deletion target ver- 
sion is restored (step S135). 

Then, the obtained (V[p(r)]) is enciphered by 
the cipher unit 112 as a new block data (step 
S136). 

Finally, this enciphered block data and the 
deletion request for the version r are transmitted 
to the server 95 (step S137). 
Next, the processing procedure of the server 
95 which received the deletion request from the 
client 92 will be described with reference to Fig. 
37. 

(i) A case in which the deletion target is not the 
first version of the records or the current version 
(a case of r + f at the step S151 and r^nat the 
step S153) 

In this case, a block data (V[r] - V[s(r)]) and 
a block data (V[p(r)] - V[r]) are deleted, and a 
block data (V[p(r)] - V[s(r)]) transmitted from the 
client 92 is inserted instead (step S155). 

(ii) A case in which the deletion target is the first 
version of the records (a case of r = f at the 
step S151) 

In this case, a block data (V[r] - V[S(r)]) is 
deleted (step S152). 

(iii) A case in which the deletion target is the last 
version (current version) of the records (a case 
of r = n at the step S1 53) 

In this case, a block data V[r] and a block 
data (V[p(r)] - V[r]) are deleted, and a block data 
V[p(r)] transmitted from the client 92 is inserted 
instead (step S154). 
By the above procedure, the record of the 
version r can be deleted. 

Next, a case in which the record management 
unit 510 is carrying out the record management 
according to the modified SCCS scheme will be 
explained. As mentioned above, in the modified 
SCCS scheme, the blocks are sequentially divided 
as the version progresses. When the number of 
blocks increases, the overhead due to the block 
identification information and the block processing 
increases, so that it is preferable not to allow a 
number of blocks to increase too much. 

As shown in Fig. 32, in a case of carrying out 
the record management by the modified SCCS 
scheme, the record management unit 510 of the 
server 95 can execute the version record deletion 
command. Consequently, it is possible to use a 
configuration in which the version deletion is car- 
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ried out by the record management unit 510 of the 
server 95, while the block reconstruction is carried 
out by the block data reconstruction unit 910 of the 
client 92. In such a case, the processing procedure 
is as follows. 

The client 92 transmits the deletion command 
for the version r to the server 95 first. 

Then, the record management unit 510 of the 
server 95 deletes the record of the version r by the 
procedure of Fig. 32. 

Then, the client 92 reads out the files of V[s(r)] 
or V[n], and carries out the block reconstruction at 
the block data reconstruction unit 910 and the 
enciphering at the cipher unit 112, and then returns 
the reconstructed block data to the server 95. Here, 
the block data that can be reconstructed are those 
block data which are continuous in their positions 
and which have the identical creation time and 
deletion time. After these blocks are deciphered, 
they are reconstructed and enciphered as an ar- 
bitrary new block data, and then transmitted to the 
server 95. 

Finally, the record management unit 510 of the 
server 95 replaces the old block with the transmit- 
ted new block data. 

It is to be noted that the feature for reconstruct- 
ing the block data according to this sixth embodi- 
ment may be incorporated into the file editing 
system with the file content secrecy feature alone 
such as that of Fig. 23 described above. 

Next, the seventh embodiment of a shared file 
editing system according to the present invention 
will be described in detail. In this seventh embodi- 
ment, the shared file editing system of Fig. 13, Fig. 
16, or Fig. 20 described above is further equipped 
with an additional function which enables the client 
who already possesses a certain version of a cer- 
tain file to read out only necessary portion of 
another version newly, rather than reading the en- 
tire file of that another version. 

Fig. 38 shows a configuration of the shared file 
editing system of this seventh embodiment as out- 
lined above, which is based on the shared file 
editing system of Fig. 13 described above. 

In this configuration of Fig. 38, the communica- 
tion path 111 is substantially similar as that in Fig. 
13. The file management server 96 differs from that 
of Fig. 13 in that it further includes a difference 
information construction unit 930, while each ac- 
cess requesting client 93 differs from that of Fig. 
13 in that it further includes a file memory unit 920 
and a file data construction unit 921. 

The client 93 stores the previously accessed 
file along with its version information in the file 
memory unit 920. In a case of reading out another 
version (such as the latest version) of the same file 
from the server 96, the client 93 notifies the cur- 
rently possessed version information and the de- 



sired version information to the server 96. Then, 
the difference information construction unit 930 of 
the server 96 constructs the difference data be- 
tween the desired version and the already pos- 

5 sessed version according to the above two version 
informations notified from the client 93, and returns 
the constructed difference data to the client 93. 
Then, the file data construction unit 921 of the 
client 93 constructs the desired version from the 

70 currently possessed file data and the difference 
data transmitted from the server 96. Then, the 
constructed desired version is handed over to the 
shared file editing unit 122 for carrying out the 
editing with respect to the desired version. 

15 In general, the difference data between ver- 

sions are smaller than the data of the entire file, so 
that the amount of communication data can be 
reduced, and the high speed read out operation 
can be realized in this seventh embodiment. 

20 Here, a method for constructing the difference 

data at the difference information construction unit 
930 of the server 96 differs depending on which 
one of the difference pile up scheme, the RCS 
scheme, and the modified SCCS scheme is used 

25 by the record management unit 510, so that an 
example for each of these three cases will be 
described one by one. 

In the following explanation, the following sym- 
bols will be used. 

30 c : a version number of the file already pos- 

sessed by the client 93 

r : a version number of a desired version to be 
newly read out by the client 93 
V[x] : (content of) version x 

as V[x] - V[y] : a difference between version x and 

version y 

First, the processing procedure for the dif- 
ference information construction unit 930 in a case 
in which the record management unit 510 is carry- 
40 ing out the record management according to the 
difference pile up scheme will be explained. 

(i) A case of reading out a version newer than 
the already possessed version (r > c) 

In this case, as the difference pile up 
45 scheme is a scheme which piles up the dif- 
ference between versions, it suffices to select 
the difference block data between the version r 
and the version c. 

(ii) A case of reading out a version older than 
so the already possessed version (r < c) 

In this case, the following two methods are 
available. 

(a) V[r] is repeated without constructing the 
difference data. 
55 In a case the block data are enciphered, 

the server cannot construct the difference 
data, so that this method should be em- 
ployed. 
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(b) The server restores V[r] and V[c], and 

obtains V[r] - V[c]. 

This method is possible when the block 

data are not enciphered. 
Next, the processing procedure for the dif- 
ference information construction unit 930 in a case 
in which the record management unit 510 is carry- 
ing out the record management according to the 
RCS scheme will be explained. Fig. 31 shows a 
flow chart for the deletion command execution pro- 
cessing in this case. 

(i) A case of reading out a version newer than 
the already possessed version (r > c) 

In this case, the following two methods are 
available. 

(a) V[r] is repeated without constructing the 
difference data. 

In a case the block data are enciphered, 
the server cannot construct the difference 
data, so that this method should be em- 
ployed. 

(b) The server restores V[r] and V[c], and 
obtains V[r] - V[c]. 

This method is possible when the block 
data are not enciphered. 

(ii) A case of reading out a version older than 
the already possessed version (r < c) 

In this case, as the RCS scheme is a 
scheme which leaves the difference between 
versions in backward direction as a record, it 
suffices to select the difference block data be- 
tween the version r and the version c. 
Next, the processing procedure for the dif- 
ference information construction unit 930 in a case 
in which the record management unit 510 is carry- 
ing out the record management according to the 
modified SCCS scheme will be explained. Fig. 39 
shows a flow chart for the processing procedure for 
the difference information construction unit 930 to 
select the difference block from the blocks con- 
stituting the record of the file. Here, the flow chart 
of Fig. 39 shows the difference block selection 
processing procedure for one block constituting the 
record. The difference block selection processing 
at the difference information construction unit 930 
is carried out by applying this procedure to all the 
blocks. 

In the following explanation, the following sym- 
bols will also be used. 

i : a creation version number of a block which 
is a processing target 

d : a deletion version number of a block which 
is a processing target 

Here, the block which is not yet deleted will be 
designated by d = NULL. 

(i) A case of reading out a version newer than 
the already possessed version (r > c at the step 
S161) 



In this case, a block satisfying either one of 
the following two conditions is selected (step 
S167). 

(a) A block which has been created during a 
5 period from the version c to the version r, 

and which has not been deleted at a time of 
the version r, i.e. , (r & i > c) and {(r < d) or 
(d = NULL)} (step S162). 

(b) A block which had already been created 
io at a time of the version c and which had 

been deleted during a period from the ver- 
sion c to the version r, i.e. , (i S c) and (r ^ d 
> c) (step S163). 

(ii) A case of reading out a version older than 
75 the already possessed version (r < c at the step 

S164) 

In this case, a block satisfying either one of 
the following two conditions is selected (step 
S167). 

20 (a) A block which has been created during a 

period from the version r to the version c, 
and which has not been deleted at a time of 
the version c, i.e., (r < i £ c) and {(d < c) or 
(d = NULL)} (step S165). 
25 (b) A block which had already been created 

at a time of the version c and which had 
been deleted during a period from the ver- 
sion r to the version c, i.e., (i £ c) and (r < d 
£ c) (step S166). 
30 After selecting the difference block by the 

above procedure, the difference information con- 
struction unit 930 converts the selected differ- 
ence block data into the difference information 
with respect to the version already possessed 
35 by the client 93, and transmits the obtained 
change information to the client 93. For exam- 
ple, for the insertion data, the insertion position 
with respect to the version possessed by the 
client 93 is obtained and transmitted together 
40 with the insertion block data. For the deletion 
data, the deletion range with respect to the 
version possessed by the client 93 is obtained 
and transmitted as it is. By means of this, the 
client 93 can construct the desired version easi- 
45 ly, and the amount of communication data from 
the server 96 to the client 93 can be kept small. 

It is to be noted that the feature for con- 
structing the desired version on the client side 
according to this seventh embodiment may be 
so incorporated into the file editing system with the 
file content secrecy feature alone such as that of 
Fig. 23 described above. 
Next, the eighth embodiment of a shared file 
editing system according to the present invention 
55 will be described in detail. In this eighth embodi- 
ment, the shared file editing system of Fig. 13, Fig. 
16, or Fig. 20 described above which has the 
asynchronous editing function is further equipped 
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with an additional function for handling the conflict 
in editing due to asynchronously occurring write 
operations from a plurality of clients with respect to 
a certain file. 

Fig. 40 shows a configuration of the shared file 5 
editing system of this eighth embodiment as out- 
lined above, which is based on the shared file 
editing system of Fig. 16 described above. 

In this configuration of Fig. 40, each access 
requesting client 211 and the communication path w 
111 are substantially similar as those in Fig. 16. 
The file management server 220 differs from that of 
Fig. 16 in that it further includes an editing conflict 
detection unit 940. 

In this eighth embodiment, just as in a case of 15 
Fig. 16, the data write requests from a plurality of 
the clients 211 occur at various timings. At the 
server 220, the write request from each client 211 
is converted into the position data with respect to 
the latest version at that timing by the editing 20 
procedure conversion unit 502. Then, at the editing 
conflict detection unit 940, whether the converted 
editing data is in conflict with the editing result 
made by the other clients 211 or not is detected. 
The obtained detection result is then returned to 25 
that each client 21 1 . 

Here, the conflict in editing can be judged 
according to the following criteria for example. 

(a) The insertion position of the insertion data 

has already been deleted. 30 

(b) The insertion position of the insertion data 
has the other data already inserted. 

(c) The deletion range has other data already 
inserted. 

(d) A part of the deletion range has already 35 
been deleted. 

At the record management unit 510, the detec- 
tion result of the editing conflict detection unit 940 
is not received, and the data transmitted from the 
client 211 and converted by the editing procedure 40 
conversion unit 502 are stored as the latest version. 

Here, the data updating by the server 220 may 
be possible or impossible depending on the man- 
agement scheme used by the record management 
unit 510 and whether or not the block data are 45 
enciphered. In a case the block data are not enci- 
phered, the data updating by the server 220 is 
possible for any of the difference pile up scheme, 
the RCS scheme, and the modified SCCS scheme. 
In a case the block data are enciphered, the data 50 
updating by the server 220 is possible only for the 
modified SCCS scheme. 

Next, the ninth embodiment of a shared file 
editing system according to the present invention 
will be described in detail. In this ninth embodi- 55 
ment, the shared file editing system of the eighth 
embodiment described above is further modified 
such that the editing conflict detection unit 940 



notifies the detection result to the record manage- 
ment unit 510 and the record management unit 510 
judges whether or not to carry out the data updat- 
ing according to the notified detection result. 

Fig. 41 shows a configuration of the shared file 
editing system of this ninth embodiment as out- 
lined above, which is based on the shared file 
editing system of Fig. 40 described above. 

In this configuration of Fig. 41, each access 
requesting client 211 and the communication path 
111 are substantially similar as those in Fig. 40. 
The file management server 225 differs from that of 
Fig. 40 in that the output of the editing conflict 
detection unit 940 is also supplied to the record 
management unit 510. 

In this ninth embodiment, when the editing 
conflict with the other clients does not occur, the 
data transmitted from the client 21 1 and converted 
by the editing procedure conversion unit 502 are 
stored as the latest version, whereas when the 
editing conflict with the other clients occurs, the 
data updating by the server 225 is not carried out. 
In this case, the latest version to which the writing 
was actually made can be known as free of the 
editing conflict with the other clients, so that there 
is an advantage that the contradiction in meaning is 
unlikely to occur. The client 211 receives the no- 
tification of the detection result obtained by the 
editing conflict detection unit 940, so that in a case 
the writing was not made, the client 21 1 can read 
out the latest version from the server and carry out 
a different editing which avoids the occurrence of 
the conflict. 

Next, the tenth embodiment of a shared file 
editing system according to the present invention 
will be described in detail. In this tenth embodi- 
ment, the shared file editing system is formed such 
that it can be utilized from the already existing 
application program. 

Fig. 42 shows a configuration of the shared file 
editing system of this tenth embodiment as out- 
lined above, which generally comprises a plurality 
of access requesting clients 950 and a file manage- 
ment server 970 which are connected through a 
communication path 111. The file management 
server 970 further includes a communication 
(COMM) unit 131, an access information memory 
unit 971, a record management unit (for shared file) 
972, and a data memory unit 973. Each access 
requesting client 950 further includes an access 
request unit 951 , a system call table 955, a shared 
file access processing unit 960, and a communica- 
tion (COMM) unit 130. Each access requesting 
client 950 and the file management server 970 can 
communicate through the communication path 111 
by means of the respective communication 
(COMM) units 130 and 131. 
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In this tenth embodiment, the access request 
unit 951 is assumed to be the already existing 
application program, and the access request issued 
from the access request unit 951 is to be executed 
by the system call provided by the operating sys- 
tem. 

In this tenth embodiment, the access request 
unit 951 refers to the functions corresponding to 
the system calls listed in the system call table 955, 
and executes one of open/close/read/write func- 
tions. The data in the system call table 955 which 
refer to the functions of the system calls in the 
operating system are rewritten from the connection 
data (address pointers) to open function/close tunc- 
tion'read function/write function provided by the 
operating system into the connection data (address 
pointers) to shared open function/shared close 
function/shared read function/shared write function 
which are provided by the shared file access pro- 
cessing unit 960. These shared open func- 
tion/shared close function/shared read func- 
tion/shared write function 961 are then transmitted 
through the communication (COMM) unit 130 to the 
file management server 970. 

Therefore, when the access request unit 951 
comprising the already existing application pro- 
gram executes the open function/close func- 
tion/read function/write function, actually the shared 
open function/shared close function/shared read 
function/shared write function 961 are going to be 
executed. 

Here, the shared open function/shared close 
function/shared read function/shared write function 
961 actually correspond to the processing accord- 
ing to the shared file access request for carrying 
out "open", the processing according to the shared 
file access request for carrying out "close", the 
processing according to the shared file access 
request for carrying out "read", and the processing 
according to the shared file access request for 
carrying out "write", respectively. It is to be noted 
that, in Fig. 42, the shared open function/shared 
close function/shared read function/shared write 
function 961 are provided separately, but the pro- 
cessing common to all these functions 961 may be 
provided as one process and shared by these four 
functions. 

The file management server 970 receives the 
shared open function/shared close function/shared 
read function/shared write function 961 from the 
access requesting client 950, and hand them to the 
record management unit 972. Then, the record 
management unit 972 can carry out the reading or 
the writing of the desired data from the data mem- 
ory unit 973 according to the information of the 
access information memory unit 971. Then, the 
executed access request is recorded as data in the 
access information memory unit 971 . 



Fig. 43 shows an example of the access record 
list 980 in the access information memory unit 971. 
This access record list 980 is a list for storing the 
access requests to the files of the file management 
5 server 970. This access record list 980 has six 
fields for a file ID 981 , a mode 982, an open time 
983, a close time 984, a version 985, and a current 
986. 

The file ID 981 is an identifier uniquely as- 

io signed to each shared file access request for 
"open" given from the access request unit 951 to 
the record management unit 972. After the "open" 
request, the shared file access requests from the 
access request unit 951 are managed by using the 

15 file ID 981. This file ID 981 is issued to the access 
request unit 951 whenever the shared file access 
request for "open" is received by the record man- 
agement unit 972. 

The mode 982 indicates a mode of the open 

20 request to this file, where "r" indicates that it is 
read only mode, and "w" indicates that it is either 
write only mode or read and write mode. 

The open time 983 indicates a time at which 
the open request to this file was issued. In this 

25 example, the file represented as ID1 is indicated as 
opened at a time t1. Also, the close time 984 
indicates a time at which the close request to this 
file was issued. In this example, the file repre- 
sented as ID1 is indicated as still open as the close 

30 time 984 is not entered , whereas the file repre- 
sented as ID2 is indicated as closed at a time t5. 

Here, the time is used to indicate the timing 
relationship among the occurrence times of various 
events, and may be given by an internal clock of a 

35 computer, or the version number used for the file 
management may be utilized as the time. Also, this 
time is used only by the record management unit 
972, so that there is no need for the other element 
such as the access requesting client 950 to be able 

40 to refer to this time directly. 

The version 985 indicates the version of the file 
from which the open request to this file has been 
issued. Usually, the system call "open" is a re- 
quest with respect to the latest version, so that this 

45 version 985 is usually given by the latest version at 
a time of issuance of the open request. 

The current 986 is a value (seek pointer) which 
indicates the currently accessed position, for the 
currently accessing access request. This seek 

so pointer indicates the read out position (relative po- 
sition within the file) to the shared file access 
request for "read" which comes next. In a case of 
the "open" in the read only mode, the initial value 
is set to be 0 as a default. 

55 The record management unit 972 manages the 

asynchronous accesses from the access request- 
ing clients 950, and carries out the read and the 
write of the desired data with respect to the data 
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memory unit 973 according to the contents of the 
access information memory unit 971. Here, the 
operation of the record management unit 972 itself 
is similar to that in the previous embodiments 
described above, so that its explanation will be 5 
omitted. 

According to this tenth embodiment described 
above, the already existing application software 
program can be utilized as the access requesting 
client for carrying out the asynchronous editing in 10 
this system, without requiring any change at all in 
the program itself, by simply rewriting the values of 
the address pointers in the system call table 955 
provided by the operating system. 

Next, the eleventh embodiment of a shared file is 
editing system according to the present invention 
will be described in detail. This eleventh embodi- 
ment is a modification of the tenth embodiment 
described above, which is aiming at the same 
purpose as the tenth embodiment. 20 

Fig. 44 shows a configuration of the shared file 
editing system of this eleventh embodiment, which 
differs from the configuration of Fig. 42 in that the 
access information memory unit 971 provided in 
the file management server 970 in Fig. 42 is now 25 
provided as the access information memory unit 
995 in the access requesting client 990 in Fig. 44. 
In this case, the file management server 90 includ- 
ing the record management unit 510, the data 
memory unit 51 1 , and the communication (COMM) 30 
unit 131 is substantially similar to that in the con- 
figuration of Fig. 13 described above. 

In this eleventh embodiment, the access re- 
questing client 990 stores the shared file access 
information from its own access request unit 991 35 
into the access information memory unit 995. The 
content of the access information memory unit 995 
can be similar to that shown in Fig. 43 described 
above, for example. 

The shared file access processing unit 993 40 
reads out the information in the access information 
memory unit 995, and transmits the request to the 
file management server 90 by adding necessary 
information to the shared open function/shared 
close function/shared read function/shared write 45 
function 994 as the arguments of the respective 
functions. 

For example, when the read system call for 
reading 10 bytes from the file with the file ID of ID1 
is issued from the access request unit 991, the 50 
shared file access processing unit 993 reads out 
the version information 985 and the current position 
information 986 concerning the file ID of ID1 from 
the access information memory unit 995, and adds 
these informations along with the file ID of ID1 and 55 
the number of bytes to be read out to the argument 
of the shared open function, and then transmits it 
tot he file management server 90. 



The request transmitted from the access re- 
questing client 990 to the file management server 
90 contains the current access information of the 
access requesting client in addition to the usual 
information given by the system call of the operat- 
ing system, so that the record management unit 
510 can take out the desired data from the data 
memory unit 511 according to that information. 

As described, even in this eleventh embodi- 
ment, the already existing application software pro- 
gram can be utilized as the access requesting 
client for carrying out the asynchronous editing in 
this system, without requiring any change at all in 
the program itself, by simply rewriting the values of 
the address pointers in the system call table 992 
provided by the operating system. 

It is to be noted that the feature for enabling 
the use of the already existing application program 
with respect to the shared files according to the 
tenth and evelenth embodiments may be utilized 
as a feature for enabling the use of the already 
existing application program with respect to the 
enciphered files, by replacing the access functions 
for the shared files in the above description by the 
access functions for the enciphered files, in the file 
editing system with the file content secrecy feature 
alone such as that of Fig. 23 described above. 

It is also to be noted that, in the various em- 
bodiments described above, the communication 
through a communication path between commu- 
nication units provided on the client and the server 
may be realized in a form of a network commu- 
nication between the client computer device and 
the server computer device, or in a form of a data 
transfer between the client program and the server 
program within a single computer device. 

It is also to be noted that, besides those al- 
ready mentioned above, many modifications and 
variations of the above embodiments may be made 
without departing from the novel and advantageous 
features of the present invention. Accordingly, all 
such modifications and variations are intended to 
be included within the scope of the appended 
claims. 

Claims 

1. A file editing system, comprising: 

a file management server device for man- 
aging files, each file containing a plurality of 
block data and block identification information 
for each block data, the block data being enci- 
phered in units of blocks, and the file manage- 
ment server device managing the files accord- 
ing to the block identification information for 
each block data; and 

at least one client device, which makes an 
access to the file management server device 
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to obtain the block data belonging to a desired 
file managed by the file management server 
device, the client device including: 

deciphering means for deciphering the 
block data obtained from the file management 5 
server device, in units of blocks by using a 
prescribed decipher key; 

editing means for editing the desired file 
formed by the block data deciphered by the 
deciphering means to obtain editing data in- w 
dicating an editing made in the desired file; 

enciphering means for enciphering the ed- 
iting data obtained by the editing means, in 
units of blocks by using a prescribed cipher 
key, to obtain enciphered editing data; and 75 

communication means for transmitting the 
enciphered editing data obtained by the enci- 
phering means to the file management server 
device, such that the file management server 
device manages the desired file according to 20 
the enciphered editing data received from the 
client device. 

2. The system of claim 1, wherein the client 
device .obtains the block data corresponding to 25 
a desired version of the desired file from the 

file management server device, and the file 
management server device includes record 
management means for carrying out a record 
management of the desired file according to 30 
the enciphered editing data for the desired 
version of the desired file received from the 
client device. 

3. The system of claim 1, wherein the client 35 
device obtains the block data corresponding to 

a desired version of the desired file from the 
file management server device, and the file 
management server device includes record 
management means for carrying out a record 40 
management of the desired file according to 
the enciphered editing data for a latest version 
of the desired file received from the client 
device. 

45 

4. The system of claim 1, wherein the file man- 
agement server device accepts access re- 
quests with respect to an identical file from 
more than one client devices asynchronously, 
such that said more than one client devices so 
carry out asynchronous editing with respect to 

said identical file. 

5. The system of claim 1, wherein the file man- 
agement server device manages each block 55 
data in a state of being enciphered by a 
stream cipher scheme, and the enciphering 
means enciphers the editing data by the 
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stream cipher scheme. 

6. The system of claim 1, wherein the client 
device further includes 

block data reconstruction means for re- 
constructing a plurality of block data deci- 
phered by the deciphering means into a new 
block data; and 

wherein the enciphering means also enci- 
phers the new block data obtained by the 
block data reconstruction means, and the com- 
munication means also transmits the new block 
data enciphered by the enciphering means to 
the file management server device, such that 
the file management server device manages 
the desired file according to the new block 
data received from the client device. 

7. The system of claim t, wherein the client 
device further includes: 

file memory means for storing a previously 
accessed version of the desired file; and 

file data construction means for construct- 
ing a desired version of the desired file ac- 
cording to the previously accessed version 
stored in the file memory means and the block 
data belonging to the desired file which are 
obtained from the file management server de- 
vice; and 

wherein the file management server device 
includes: 

difference construction means for con- 
structing the block data to be given to the 
client device by obtaining difference between 
the previously accessed version and the de- 
sired version. 

8. The system of claim 1, wherein the client 
device further includes: 

access request means for issuing an ac- 
cess request in terms of system calls provided 
by an operating system, with respect to a file 
formed by the block data which are enciphered 
and managed by the file management server 
device; 

system call table means for registering 
address pointers corresponding to the system 
calls; and 

file access processing means for obtaining 
a file access request to be transmitted from 
the client device to the file management server 
device, according to the address pointers reg- 
istered in the system call table means cor- 
responding to the system calls specified by 
the access request issued at the access re- 
quest means. 
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9. A file editing system, comprising: 

a file management server device for man- 
aging files, each file containing a plurality of 
block data and block identification information 
for each block data, and the block data being s 
enciphered in units of blocks; and 

at least one client device, which makes an 
access to the file management server device 
to obtain the block data corresponding to a 
desired version of a desired file managed by w 
the file management server device, the client 
device including: 

deciphering means for deciphering the 
block data obtained from the file management 
server device, in units of blocks by using a 75 
prescribed decipher key; 

editing means for editing the desired ver- 
sion of the desired file formed by the block 
data deciphered by the deciphering means; 

editing procedure generation means for 20 
generating editing procedure data indicating a 
procedure to obtain an editing made in the 
desired version of the desired file by the ed- 
iting means; 

editing procedure conversion means for 25 
converting the editing procedure data for the 
desired version of the desired file generated 
by the editing procedure generation means 
into editing procedure data for a latest version 
of the desired file; 30 

record management information generation 
means for generating record management in- 
formation indicating a result of the editing 
made by the editing means, according to the 
editing procedure data for the latest version of 35 
the desired file obtained by the editing proce- 
dure conversion means; 

enciphering means for enciphering the 
record management information generated by 
the record management information generation 40 
means, in units of blocks by using a pre- 
scribed cipher key, to obtain enciphered 
record management information; and 

communication means for transmitting the 
enciphered record management information 45 
obtained by the enciphering means to the file 
management server device; 

wherein the file management server device 
includes: 

record management means for carrying 50 
out a record management of the desired file 
according to the enciphered record manage- 
ment information received from the client de- 
vice and the block identification information for 
each block data. 55 

10. The system of claim 9, wherein the file man- 
agement server device transmits record data 



according to which the record management of 
the desired file is carried out by the file man- 
agement server device to the client device, 
and the editing procedure conversion means 
obtains the editing procedure data for the lat- 
est version of the desired file according to a 
relationship between the desired version and 
the latest version indicated by the record data. 

11. The system of claim 9, wherein the file man- 
agement server device manages each file in a 
form of a first block data in which an originally 
created file content is enciphered, subsequent 
block data in which difference between a file 
content before each editing and a file content 
after each editing is enciphered, and the block 
identification information attached to each 
block data which identifies each block data. 

12. The system of claim 9, wherein the file man- 
agement server device manages each file in a 
form of a latest block data in which a latest 
edited file content is enciphered, previous 
block data in which difference between a file 
content before each editing and a file content 
after each editing is enciphered, and the block 
identification information attached to each 
block data which identifies each block data. 

13. The system of claim 9, wherein the file man- 
agement server device manages each file in a 
form of insertion block data in which each 
content inserted into each file is enciphered, 
deletion block data in which each content de- 
leted from each file is enciphered, and the 
block identification information attached to 
each block data which identifies a creation 
time and a deletion time of each block data. 

14. The system of claim 13, wherein the file man- 
agement server device manages each block 
data in a state of being enciphered by an 8 bit 
CFB mode type cipher scheme, and the enci- 
phering means enciphers the record manage- 
ment information by the 8 bit CFB mode type 
cipher scheme. 

15. The system of claim 9, wherein the file man- 
agement server device manages each block 
data in a state of being enciphered by a 
stream cipher scheme, and the enciphering 
means enciphers the record management in- 
formation by the stream cipher scheme. 

16. The system of claim 9, wherein the record 
management information generation means at- 
taches the block identification information for 
the block data resulting from the editing made 
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by the editing means to the record manage- 
ment information, and the communication 
means transmits the enciphered record man- 
agement information along with the block iden- 
tification information attached to the record 
management information. 

17. The system of claim 9, wherein the record 
management means attaches the block iden- 
tification information for the block data result- 
ing from the editing made by the editing 
means to the enciphered record management 
information. 

18. A file editing system, comprising: 

a file management server device for man- 
aging files, each file containing a plurality of 
block data and block identification information 
for each block data; and 

at least one client device, which makes an 
access to the file management server device 
to obtain the block data corresponding to a 
desired version of a desired file managed by 
the file management server device, the client 
device including: 

deciphering means for deciphering the 
block data obtained from the file management 
server device, by using a prescribed decipher 
key; 

editing means for editing the desired ver- 
sion of the desired file formed by the block 
data deciphered by the deciphering means; 

editing procedure generation means for 
generating editing procedure data indicating a 
procedure to obtain an editing made in the 
desired version of the desired file by the ed- 
iting means and including insertion data to be 
inserted into the desired file; 

enciphering means for enciphering the in- 
sertion data included in the editing procedure 
data generated by the editing procedure gen- 
eration means, by using a prescribed cipher 
key, to obtain enciphered editing procedure 
data; and 

communication means for transmitting the 
enciphered editing procedure data obtained by 
the enciphering means to the file management 
server device; 

wherein the file management server device 
includes: 

editing procedure conversion means for 
converting the enciphered editing procedure 
data for the desired version of the desired file 
received from the client device into enciphered 
editing procedure data for a latest version of 
the desired file; 

record management information generation 
means for generating record management in- 



formation indicating a result of the editing 
made by the editing means, according to the 
enciphered editing procedure data for the lat- 
est version of the desired file obtained by the 

5 editing procedure conversion means; and 

record management means for carrying 
out a record management of the desired file 
according to the record management informa- 
tion obtained by the record management in- 

io formation generation means and the block 

identification information for each block data. 

19. The system of claim 18, wherein the editing 
procedure conversion means obtains the enci- 

75 phered editing procedure data for the latest 

version of the desired file according to a rela- 
tionship between the desired version and the 
latest version indicated by record data accord- 
ing to which the record management means 

20 carries out the record management of the de- 

sired file. 

20. The system of claim 18, wherein the file man- 
agement server device manages each file in a 

25 form of a first block data in which an originally 

created file content is enciphered, subsequent 
block data in which difference between a file 
content before each editing and a file content 
after each editing is enciphered, and the block 

30 identification information attached to each 

block data which identifies each block data. 

21. The system of claim 18, wherein the file man- 
agement server device manages each file in a 

35 form of a latest block data in which a latest 

edited file content is enciphered, previous 
block data in which difference between a file 
content before each editing and a file content 
after each editing is enciphered, and the block 

40 identification information attached to each 

block data which identifies each block data. 

22. The system of claim 18, wherein the file man- 
agement server device manages each file in a 

45 form of insertion block data in which each 

content inserted into each file is enciphered, 
deletion block data in which each content de- 
leted from each file is enciphered, and the 
block identification information attached to 

so each block data which identifies a creation 

time and a deletion time of each block data. 

23. The system of claim 22, wherein the file man- 
agement server device manages each block 

55 data in a state of being enciphered in units of 

blocks by an 8 bit CFB mode type cipher 
scheme, and the enciphering means enciphers 
the insertion data by the 8 bit CFB mode type 
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cipher scheme. 

24. The system of claim 18, wherein the file man- 
agement server device manages each block 
data in a state of having at least insertion data 5 
portion of each block data enciphered by a 
stream cipher scheme, and the enciphering 
means enciphers the insertion data by the 
stream cipher scheme. 

10 

25. The system of claim 18, wherein one of the 
record management information generation 
means and the record management means 
attaches the block identification information for 

the block data resulting from the editing made 75 
by the editing means to the record manage- 
ment information. 

26. A shared file editing system, comprising: 

a file management server device for man- 20 
aging files, each file containing a plurality of 
block data and block identification information 
for each block data; 

a plurality of client devices, each client 
device making an access to the file manage- 25 
ment server device to obtain the block data 
corresponding to a desired version of a de- 
sired file managed by the file management 
server device, and editing the desired file 
formed by the block data obtained from the file 30 
management server device; and 

asynchronous editing support means for 
supporting asynchronous editing by said plu- 
rality of client devices, including: 

editing procedure generation means for 35 
generating editing procedure data indicating a 
procedure to obtain each editing made in the 
desired file by each client device; 

editing procedure conversion means for 
converting the editing procedure data for the 40 
desired version of the desired file generated 
by the editing procedure generation means 
into editing procedure data for a latest version 
of the desired file; and 

record management information generation 45 
means for generating record management in- 
formation indicating a result of the editing 
made in the desired file by each client device, 
according to the editing procedure data for the 
latest version of the desired file obtained by 50 
the editing procedure conversion means, such 
that the file management server device man- 
ages the desired file according to the record 
management information and the block iden- 
tification information for each block data. 55 

27. The system of claim 26, wherein the file man- 
agement server device includes: 



client counting means for counting a num- 
ber of client devices which are currently ed- 
iting each version of each file, in correspon- 
dence to each version of each file managed by 
the file management server device; and 

deletion delay means for delaying an ex- 
ecution of a deletion of a particular version of a 
particular file in response to a request for de- 
leting the particular version of the particular file 
until said number of client devices counted by 
the client counting means becomes zero. 

28. The system of claim 26, wherein each client 
device includes: 

block data reconstruction means for re- 
constructing a plurality of block data obtained 
from the file management server device into a 
new block data; and 

wherein each client device transmits the 
new block data obtained by the block data 
reconstruction means to the file management 
server device, such that the file management 
server device manages the desired file accord- 
ing to the new block data received from the 
client device. 

29. The system of claim 26. wherein each client 
device includes: 

file memory means for storing a previously 
accessed version of the desired file; and 

file data construction means for construct- 
ing a desired version of the desired file ac- 
cording to the previously accessed version 
stored in the file memory means and the block 
data belonging to the desired file which are 
obtained from the file management server de- 
vice; and 

wherein the file management server device 
includes: 

difference construction means for con- 
structing the block data to be given to the 
client device by obtaining difference between 
the previously accessed version and the de- 
sired version. 

30. The system of claim 26, wherein the file man- 
agement server device includes: 

editing conflict detection means for detect- 
ing an occurrence of a conflict between an 
editing made by one client device and another 
editing made by another client device, and 
notifying the detected occurrence of the con- 
flict to said one client device. 

31. The system of claim 30, wherein the file man- 
agement server device further includes: 

record management means for carrying 
out a record management of the desired file 
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according to the record management informa- 
tion obtained by the asynchronous editing sup- 
port means for said one client device, only 
when the editing conflict detection means does 
not detect the occurrence of the conflict for 5 
said one client device. 

32. The system of claim 26, wherein each client 
device includes: 

access request means for issuing an ac- io 
cess request in terms of system calls provided 
by an operating system, with respect to a 
shared file managed by the file management 
server device; 

system call table means for registering 75 
address pointers corresponding to the system 
calls; and 

shared file access processing means for 
obtaining a shared file access request to be 
transmitted from each client device to the file 20 
management server device, according to the 
address pointers registered in the system call 
table means corresponding to the system calls 
specified by the access request issued at the 
access request means. 25 

33. A method of file editing in a file editing system 
formed by a file management server device 
and at least one client device, comprising the 
steps of: 30 

managing files at the file management 
server device, each file containing a plurality of 
block data and block identification information 
for each block data, the block data being enci- 
phered in units of blocks, and the file manage- 35 
ment server device managing the files accord- 
ing to the block identification information for 
each block data; 

making an access to the file management 
server device to obtain the block data belong- 40 
ing to a desired file managed by the file man- 
agement server device, at the client device; 

deciphering the block data obtained from 
the file management server device, in units of 
blocks by using a prescribed decipher key, at 45 
the client device; 

editing the desired file formed by the block 
data deciphered by the deciphering step to 
obtain editing data indicating an editing made 
in the desired file, at the client device; 50 

enciphering the editing data obtained by 
the editing step, in units of blocks by using a 
prescribed cipher key, to obtain enciphered 
editing data at the client device; and 

transmitting the enciphered editing data 55 
obtained by the enciphering step from the cli- 
ent device to the file management server de- 
vice, such that the file management server 
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device manages the desired file according to 
the enciphered editing data received from the 
client device. 

34. A method of file editing in a file editing system 
formed by a file management server device 
and at least one client device, comprising the 
steps of: 

managing files at the file management 
server device, each file containing a plurality of 
block data and block identification information 
for each block data, and the block data being 
enciphered in units of blocks; 

making an access to the file management 
server device to obtain the block data cor- 
responding to a desired version of a desired 
file managed by the file management server 
device, at the client device; 

deciphering the block data obtained from 
the file management server device, in units of 
blocks by using a prescribed decipher key, at 
the client device; 

editing the desired version of the desired 
file formed by the block data deciphered by 
the deciphering step, at the client device; 

generating editing procedure data indicat- 
ing a procedure to obtain an editing made in 
the desired version of the desired file by the 
editing step, at the client device; 

converting the editing procedure data for 
the desired version of the desired file gen- 
erated by the editing procedure data generat- 
ing step into editing procedure data for a latest 
version of the desired file, at the client device; 

generating a record management informa- 
tion indicating a result of the editing made at 
the editing step, according to the editing pro- 
cedure data for the latest version of the de- 
sired file obtained by the converting step, at 
the client device; 

enciphering the record management infor- 
mation generated by the record management 
information generating step, in units of blocks 
by using a prescribed cipher key, to obtain 
enciphered record management information at 
the client device; 

transmitting the enciphered record man- 
agement information obtained by the encipher- 
ing step from the client device to the file 
management server device; and 

carrying out a record management of the 
desired file at the file management server de- 
vice, according to the enciphered record man- 
agement information received from the client 
device and the block identification information 
for each block data. 



73 



EP 0 674 253 A1 



74 



35. A method of file editing in a file editing system 
formed by a file management server device 
and at least one client device, comprising the 
steps of: 

managing files at a file management serv- 5 
er device, each file containing a plurality of 
block data and block identification information 
for each block data; 

making an access to the file management 
server device to obtain the block data cor- io 
responding to a desired version of a desired 
file managed by the file management server 
device, at the client device; 

deciphering the block data obtained from 
the file management server device, by using a is 
prescribed decipher key, at the client device; 

editing the desired version of the desired 
file formed by the block data deciphered by 
the deciphering step, at the client device; 

generating editing procedure data indicat- 20 
ing a procedure to obtain an editing made in 
the desired version of the desired file by the 
editing step and including insertion data to be 
inserted into the desired file, at the client de- 
vice; 25 

enciphering the insertion data included in 
the editing procedure data generated by the 
editing procedure data generating step, by us- 
ing a prescribed cipher key, to obtain enci- 
phered editing procedure data at the client 30 
device; 

transmitting the enciphered editing proce- 
dure data obtained by the enciphering step 
from the client device to the file management 
server device; 35 

converting the enciphered editing proce- 
dure data for the desired version of the desired 
file received from the client device into enci- 
phered editing procedure data for a latest ver- 
sion of the desired file, at the file management 40 
server device; 

generating record management information 
indicating a result of the editing made by the 
editing step, according to the enciphered ed- 
iting procedure data for the latest version of 45 
the desired file obtained by the converting 
step, at the file management server device; 
and 

carrying out a record management of the 
desired file at the file management server de- 50 
vice, according to the record management in- 
formation obtained by the record management 
information generating step and the block iden- 
tification information for each block data. 

55 

36. A method of shared file editing in a shared file 
editing system formed by a file management 
server device and a plurality of client devices, 



comprising the steps of: 

managing files at the file management 
server device, each file containing a plurality of 
block data and block identification information 
for each block data; 

making an access to the file management 
server device to obtain the block data cor- 
responding to a desired version of a desired 
file managed by the file management server 
device, at each client device; 

editing the desired file formed by the block 
data obtained from the file management server 
device, at each client device; 

generating editing procedure data indicat- 
ing a procedure to obtain an editing made in 
the desired file by each client device at the 
editing step; 

converting the editing procedure data for 
the desired version of the desired file obtained 
at the editing procedure data generating step 
into editing procedure data for a latest version 
of the desired file; and 

generating record management information 
indicating a result of the editing made in the 
desired file by each client device at the editing 
step, according to the editing procedure data 
for the latest version of the desired file ob- 
tained by the converting step, such that the file 
management server device manages the de- 
sired file according to the record management 
information and the block identification infor- 
mation for each block data. 
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